Daishuo's Blog

Email-Worm.Nyxem.e breaks out on 3rd of every month. Feb 3 2006 was the first wave, and the worm comes back today. Nyxem will delete the content of many types of files. Affected file extensions are doc, xls, mdb, mde, ppt, pps, zip, rar, pdf, psd and dmp. So, update your antivirus software to latest definitions and launch a complete scan for your system, now.

There're a lot of public articles criticizing Google for its long-life cookie. Some people said that Google's cookie will live until 2038, and will provide Google with users' privacy information. Is that true?

First, let's take a look at the cookie returned by Google's server.

----- Hypertext Transfer Protocol -----
  HTTP/1.1 302 Found
  Via: 1.1 JMNAT
  Connection: Keep-Alive
  Proxy-Connection: Keep-Alive
  Content-Length: 230
  Date: Fri, 24 Feb 2006 05:26:23 GMT
  Location: http://www.google.com/intl/zh-CN/
  Content-Type: text/html
  Server: GWS/2.1
  Set-Cookie: PREF=ID=4b4b9263ceac921c:NW=1:TM=1140758783:LM=1140758783:S=8w8TB7lbqqrX0cPr; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com

It's written clearly that the cookie will expire in Jan 2038. But I don't think it will reside in a PC for that long unless someone never buy a new computer and never reinstall his /her operating system for the next 30 years.

There does exist an ID in the cookie. Everytime a user search for something via Google, the ID is sent along with keywords. It's possible that Google records the relationship between IDs and keywords. But obviously, IDs are not users themselves. Once you deleted all cookies and visited google.com again, you got a new ID from Google. And hence, Google might knows ID:23def263ceac921c searched for 'Valentine gifts' on Feb 14 2006, but it never knows who owned that ID. That's a keypoint when talking about Google cookie's privacy problems.

Long-life cookies are not Google's patent. I snapped some response from Baidu.com, which is the biggest local search engine in China and found that Baidu did the same thing. See the package content below,

----- Hypertext Transfer Protocol -----
   HTTP/1.1 200 OK
   Via: 1.1 JMNAT
   Connection: Keep-Alive
   Proxy-Connection: Keep-Alive
   Content-Length: 2897
   Expires: Sat, 25 Feb 2006 05:43:50 GMT
   Date: Fri, 24 Feb 2006 05:43:50 GMT
   Content-Type: text/html
   ETag: "2d6948-b51-43f1b3f8"
   Server: Apache/1.3.27
   Set-Cookie: BAIDUID=EADF79F31A5499E2EAC499CF0C8C283D;
expires=Fri, 24-Feb-36 05:43:50 GMT; path=/; domain=.baidu.com
   Cache-Control: max-age=86400
   Last-Modified: Tue, 14 Feb 2006 10:42:00 GMT
   Accept-Ranges: bytes

A summary to Google's cookie,
1, it expires on 17-Jan-2038
2, it assigns an ID to you without knowing who you are
3, it will never know who you are
4, it's famous because of its maker, not itself

Windows Media Player BMP Heap Overflow

Reference:

http://www.eeye.com/html/research/advisories/AD20060214.html
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0006
http://www.microsoft.com/technet/security/bulletin/ms06-005.mspx

The problem is in wmp.dll, see the following codes:

.text:075753A8    mov     edi, [ebp+arg_8]
.text:075753AB    lea     ecx, [ebp+var_8]
.text:075753AE    push    ecx
.text:075753AF    push    0Eh
.text:075753B1    lea     ecx, [ebp+Header]
.text:075753B4    xor     ebx, ebx
.text:075753B6    push    ecx
.text:075753B7    mov     [eax], ebx
.text:075753B9    mov     eax, [edi]
.text:075753BB    push    edi
.text:075753BC    call    dword ptr [eax+0Ch] ; Read BMP Header(0x0e bytes)
.text:075753BF    mov     esi, eax
.text:075753C1    cmp     esi, ebx
.text:075753C3    mov     eax, [ebp+Header.bfOffBits]
.text:075753C6    jl      short loc_75753FD
.text:075753C8    cmp     [ebp+var_8], 0Eh ; 0x0e bytes have been read?
.text:075753CC    jnz     loc_75756A0
.text:075753D2    cmp     [ebp+Header.bfType], 4D42h ; check BMP magic
.text:075753D8    jnz     loc_75756A0
.text:075753DE    cmp     [ebp+Header.bfReserved1], bx ; Reserved1==0?
.text:075753E2    jnz     loc_75756A0
.text:075753E8    cmp     [ebp+Header.bfReserved2], bx ; Reserved2==0?
.text:075753EC    jnz     loc_75756A0
.text:075753F2    cmp     eax, 47Ch
.text:075753F7    ja      loc_75756A0     ; bfOffBits > 0x47C?
.text:075753FD
.text:075753FD loc_75753FD:  ; CODE XREF: sub_757539A+2Cj
.text:075753FD 
.text:075753FD    cmp     esi, ebx
.text:075753FF    mov     [ebp+var_4], ebx
.text:07575402    jl      short loc_757544A
.text:07575404    lea     esi, [eax-0Eh]  ; bfOffBits - 0x0e
.text:07575407    push    eax; bfOffBits
.text:07575408    mov     [ebp+var_C], esi
.text:0757540B    call    ??2@YAPAXI@Z    ; operator new(uint)
.text:07575410    cmp     eax, ebx
.text:07575412    pop     ecx
.text:07575413    mov     [ebp+var_4], eax ; allocates buffer, bfOffBits bytes
.text:07575416    jz      loc_76FA50D
.text:0757541C    mov     ecx, [edi]
.text:0757541E    lea     edx, [ebp+var_8]
.text:07575421    push    edx
.text:07575422    push    esi
.text:07575423    push    eax
.text:07575424    push    edi
.text:07575425    call    dword ptr [ecx+0Ch] ; read (bfOffBits-0x0e) into buffer
.text:07575428    mov     esi, eax
.text:0757542A    cmp     esi, ebx
.text:0757542C    jl      short loc_757544A

As we can see in the above codes, wmp.dll first allocates a buffer which is as big as bfOffBits bytes large, and then copies (bfOffBits - 0x0e) bytes into the buffer. Problem comes when bfOffBits is less than 0x0e.

Let's suppose that bfOffBits is 0x02. wmp.dll will allocate a 2-byte-large buffer, and try to copy (0x02-0x0e=)0xfffffff4 bytes data into it. In such cases, all remained file data besides the BMPFILEHEADER will be copied. And hence, a heap overflow happens.

Fang Xing's original vulnerability report on www.eeye.com seems to be a little confusing. He wrote: "a bmp file which declares its size as 0", while actually talking about "a bmp file which declares its bfOffBits as 0".