“Estremamente critica” la vulnerabilità riscontrata sulle versioni di MSN Messenger precedenti alla 8.1 postata su un forum cinese, tanto da costringere la Microsoft nell’ esortare gli utenti a migrare a Windows Live Messenger 8.1.

L’exploit, disponibile quì, sfrutta un errore nell’handling delle video-conversazioni e può essere utilizzato per eseguire un heap-based buffer overflow causato dall’inondare l’utente vittima con pacchetti appositamente “forgiati” e spediti da chi attacca. Questo overflow di pacchetti farà crashare il programma dando in questo modo all’attaccante stesso la possibilità di sovrascrivere alcune aree di memoria del software per iniettarne del suo (shell e quant’altro) al fine di prendere il controllo della macchina dell’utente vittima.

Secunia avverte che questa falla potrebbe consentire l’esecuzione di codice arbitrario, ma richiede che la vittima accetti l’invito attraverso la Webcam.

Windows Live Messenger 8.1, non è vulnerabile a questa falla, dice un responsabile di Mcrosoft, esortando ancora una volta gli utenti a passare presto da Messenger 8.0 al Messenger 8.1. “Una volta fatte le opportune indagini, prenderemo appropriate contromisure per proteggere gli utenti.”

Tutte le versioni di Messenger precedenti alla ver. di Window Live Messenger 8.1 sono da ritenersi vulnerabili.

Estratto dell’exploit .

Data transmission part: MSN altogether uses 3 transmissions methods.

UDP, TCP and retransmits through server, because I test completely automatically use UDP, the most main transmission method also is UDP, under we discuss UDP partially, the TCP partial transmissions method basic is same, the MSN video conversation code partially uses WMV9/3, WebCam partially uses ML20 1. video conversation Each UDP packet possibly contains with video and the audio two kind of forms, general audio in front, video in after.

Each UDP packet besides corresponding UDP, but also includes 10 bytes MSN the conversation head, under launches the discussion on this 10 bytes: (UDP header) 6.281690094 billion b4 cd 08 0a 04 (payload) Behind 62 representatives is a video frequency content, when this byte makes this operation (0×62 1) & 0xF = 1 is video, is when 5 is audio (generally is 0×4a), when is 2 is sync/ack, and when is 3 is the auth package.

Following two bytes are the short integer, after 0×6981, right lateral 5 are the payload length (0×6981 5), this count for much, because packet possibly contains many payload, this must carefully calculate. The 4th byte count for much, this byte makes this operation (0×00&63 = 0) the after value 0, indicated this is composes complete frame first payload), if is 01, representative for second part. Under is 4 byte integers (5.,6,7,8 million bytes), is the transmission time, is not very important. The 9th byte (0×0a) is the complete frame serial number, identical frame different packet are partial, this byte should be same, this may take puts together a package of important basis. The 10th byte (0×04) indicated this complete frame needs several parts, 4 represents this complete frame (0×0a) to need to spell by 4 parts. 2. WebCam Slightly has the difference with video conversation, it does not bring the audio information, it has 9 bytes the heads, under launches the discussion on this 9 bytes: (UDP header) 9d 49 e1 8e 4a 09 be 09 0a (payload) The 12th byte represents the payload length (0×499d & 2,047 = 413), the behind payload length was 413. Simultaneously also represents the packet type (0×499d 11 & 7 = 1), 1 represents the video content, 2,3 ack/syn. Following 4 bytes represent timestamp, is unimportant. The 7th byte (0xbe) is the complete frame serial number, identical frame different packet are partial, this byte should be same, this may take puts together a package of important basis. The 8th byte count for much, 0×09 indicated this composes complete frame 10th payload, if is 01, the representative for the second part, to this analogizes. The question leaves in here, in all 7.x edition, has not all inspected these 1 byte, when this byte value is bigger than was equal to 0×83 time, heap overflow has produced, ha-ha. The 9th byte (0×0a) indicated this complete frame needs several parts, 0×0a represents this complete frame (0xbe) to need to spell by 10 parts. WebCam partially uses the ML20 code, in the frame first part (8th byte is 0), after follows close on 9 byte webcam is the ML20 encoded head, probably constitutes by these parts.

Int16 header size

Int16 width

Int16 height

Int16 flags (bit 1 == keyframe)

Int32 payload size

Int32 FCC (== “ML20″)

Int32 wtf

Int32 timestamp

This code in principle windows may analyze, the method basically with video conversation is same.

Via secunia.