Team 509's Home - MSN messenger 7.x (8.0?)VIDEO协议分析及一个remote heap overflow

A python bytecode decompiler : www.depython.net

(update a remote DOS exp 2007-8-31)

这个问题我发现很久了，前两天MS通知我补掉了，所以现在我公布在这里了。这个源于我在2005年底作协议分析时的偶然发现，呵呵，从此我对发现漏洞产生了兴趣。

2005年的协议分析我写的原版在这里:

http://projects.collabora.co.uk/trac/farsight/wiki/MsnVideoConversation

英文很差，写成这样不错了，哈哈。

感谢ole andre 对我的帮助，thank you very much.

WebCam（UDP）:

After auth& anything else like you wrote in tcp method, if WebCam decided to transfer data with UDP, there are 3 types packet:

1. data-transfer packet

the packet has a 9 bytes WebCam header, we discuss them with the example:

（UDP header）9d 49 e1 8e 4a 09 be 09 0a ( payload)

First two bytes used as payload size and packet types. The two bytes used as a short I nteger(0x499d) , 0x499d & 2047 = 413, it’s the length of payload. 0x499d >> 11 & 7 = 1. 1 meaning the packet type is data-transfer packet , if 2 , syn packet , if 3 , ack packet (right?)

The next four bytes are timestamp.

The 7^th byte is the frame index number .

The 8^th byte is the chunk index number

The 9^th byte is the total chuck number of the frame.

In our example , 0xbe means the packet has the number 0xbe frame’s chunk , and 0x09 means the packet has the payload of 10^th chunk , and 0x0a means the full frame has 10 chunks.

msn messager used the method to get a full frame from different packets.

The webcam used ML20 decoder & encoder , In chunk 0, after the webcam header is th e ML20 header .

2. ack packet.

3. syn packet.

the MSN messenger 7.x webcam recived-packet-processing function

only check the num_chunks, not check the chunk_index,

when chunk_index above or equal 0x83 , this type packet will cause

a heap overflow problem. the problem could allow an attacker

to gain control over the computer which installed the MSN messenger 7.x .

Video conversation (UDP):

Video conversation used WMV3 encode & decode the video.

1 data-transfer packet

the packet has a 10 bytes Video_con header, But in a packet, maybe exists different type (video & audio)payloads , so in a packet, maybe there are 2 or more Video_con header . I waste some time to know it . we discuss them with the example:

（UDP header）62 81 69 00 94 b4 cd 08 0a 04 ( payload)

The 1^st byte 0x62 means it’s a video payload, if 0x4a, means audio payload, (0x62 >> 1) & 0xF = 1 (video), (0x4a >> 1) & 0xF = 5 (audio), 2(syn/ack), 3(auth)

The next 2 bytes are length of the payload, in our example, 0x6981 >> 5 =844,844 is the length of the payload. A packet can contain 2 or more payload,So be careful to the value of the length.

The 4^th byte is the chunk index number

The next four bytes is timestamp.

The 9^th byte is the frame index number

The 10^th byte is the total chuck number of the frame

In our example , 0x0a means the payload has the number 0x0a frame’s chunk , and 0x00 means the packet has the payload of 1st chunk , and 0x04 means the full frame has 4 chunks.

msn messager used the method to get a full frame from different packets.

Maybe video_con decode the frame, it’s always a 320x240 bitmap(right?)

2.audio

3. ack/syn

4 auth

MSN VIDEO 的协议分为两个大部分，webcam和video conversation, 其中以video conversation部分最为重要，下面我们主要讨论video conversation部分，附带讨论webcam.

协商部分：与标准的MSNMS相同，请参阅相关文档。

数据传输部分：MSN一共采用3种传输方法，UDP,TCP和通过server转发，由于我的测试全部自动采用UDP,最主要的传输方法也为UDP,下面我们讨论UDP部分，TCP部分的传输方法基本相同，MSN video conversation的编码部分采用WMV9/3 , WebCam部分采用ML20

1． video conversation

每一个UDP packet可能含用video和audio两种格式，一般audio在前,video在后。

每一个UDP packet除相应的UDP头外，还含有一个10 bytes的MSN conversation头，下面就这10 bytes 展开讨论：

（UDP header）62 81 69 00 94 b4 cd 08 0a 04 ( payload)

62代表后面是一个视频的内容，当这个字节做这个运算(0x62 >> 1) & 0xF = 1 时为video ,为5时为audio(一般是0x4a),为2时为sync/ack,为3时是auth包。

下面两个字节为短整数，0x6981,右移5位后为payload长度 (0x6981 >> 5 )，这个非常重要，因为一个packet可能含多个payload,这个要小心计算。

第4个字节非常重要,这个字节做这个运算(0x00&63 = 0)后的值 0 ，表明这是组成一个完整的frame的第一个payload)，如果为01，代表为第二部分。

下面是一个4字节的整数(5,6,7,8字节)，是发送的时间，不是很重要。

第9个字节(0x0a)是完整的frame 的序号,同一个frame的不同packet部分，这字节应该相同，这可以作为拼包的重要依据。

第10个字节(0x04)表明这个完整的frame需要几个部分，4代表这个完整的frame（0x0a）需要由4部分拼成。

2. WebCam

与video conversation稍有不同，它不带audio信息，它带有一个9个字节的头，下面就这 9 bytes 展开讨论：

（UDP header）9d 49 e1 8e 4a 09 be 09 0a ( payload)

第一二个字节代表payload长度(0x499d & 2047 = 413),后面的payload长度就为413了。

同时也代表packet类型 (0x499d >> 11 & 7 = 1) , 1代表video内容，2,3 ack/syn.

下面4个字节代表timestamp,不重要。

第7个字节(0xbe)是完整的frame 的序号,同一个frame的不同packet部分，这字节应该相同，这可以作为拼包的重要依据。

第8个字节非常重要, 0x09表明这是组成一个完整的frame的第10个payload，如果为01，代表为第二部分,以此类推。问题就出在这里，在所有7.x版本里，都没有检查这1个字节，当这个字节的值大于等于0x83的时候，heap overflow 就产生了，呵呵。

第9个字节(0x0a)表明这个完整的frame需要几个部分，0x0a代表这个完整的frame（0xbe）需要由10部分拼成。

WebCam部分采用ML20编码，在frame的第一部分（第8个字节为0）,紧跟9字节webcam头后是ML20编码的头，大概由这几部分构成。

int16 header size

int16 width

int16 height

int16 flags (bit 1 == keyframe)

int32 payload size

int32 FCC (== "ML20")

int32 wtf

int32 timestamp

这个编码原则上windows可以解析的，方法同video conversation基本上一样。

我写了一个exploit在这里，为了不被人滥用，作了些修改,J

http://www.team509.com/exp_msn.rar

thanks ole andre again, His ospy is perfect.

1.compile the dll.
2.inject the dll to msn messenger 7.0.777.0 's process.
3. choose "send my webcam" to a contact id who is online using 7.x （8.0?）.
4.when the otherside accept the invatation , the otherside's msn will be at least crashed, if you using aChinese version windows 2000 sp4 , maybe a reverse shell , if other verison windows 2000, you need adjust the jmpa address in the dll's sourcecode. //这里不对了，呵呵，要改的地方多了。

The second exploit is about a remote DoS of video conversation, I report it to MSRC also last year,

they said they have patched it in live messenger 8.1, so I put a demo exploit here.

http://www.team509.com/exp_msn2.rar

A python bytecode decompiler : www.depython.net