[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20070613143454.DBB17DA820@mailserver8.hushmail.com>
Date: Wed, 13 Jun 2007 10:34:53 -0400
From: "Joey Mengele" <joey.mengele@...hmail.com>
To: <thomas@...einc.com>,<ge@...uxbox.org>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
dailydave@...ts.immunitysec.com
Subject: Re: Windows Oday release
Dear all,
Gadi Evron is a brilliant genius, much smarter than Thomas Lim.
J
On Tue, 12 Jun 2007 16:21:56 -0400 ge@...uxbox.org wrote:
>On 2007-06-13 02:58+0800, Thomas Lim wrote:
>>dear all
>
>Dear all, this is not a 0day, it is a public release of a
>responsibly
>disclosed vulnerability.
>
>Thank you for sharing your research,
>
> Gadi.
>
>>
>>SChannel Off-By-One Heap Corruption
>>===================================
>>
>>Discovery Date:
>>28th August 2006
>>
>>Date reported to Microsoft:
>>19th March 2007
>>
>>Summary:
>>The Secure Channel (SChannel) library on WinXP-SP1/SP2 is
>vulnerable to
>>a off-by-one heap buffer overwrite. The SChannel library
>implements
>>PCT/TLS/SSL protocols exported via the Security Service Provider
>Interface
>>(SSPI). It is one of several Security Service Providers loaded-in
>and
>>supported
>>by the privileged Local Security Authority (Lsass.exe) process.
>>
>>In SChannel's implementation of the client-side SSLv3 handshake
>protocol,
>>specifically in the processing of the server-key-exchange SSL
>handshake
>>record, there is insufficient checks for malformed server-sent
>digital
>>signature,
>>with its length-field set to 0. This results in a allocation of a
>
>>0-length heap
>>buffer (with a valid heap address). A reverse memory copy is then
>
>>performed to
>>copy-in the digital signature, by decrementing the 0-length by 1.
>This
>>results in
>>an integer-underflow, causing the heap-buffer pointer to
>decrement
>>before its start
>>address, ultimately leading to an overwrite of exactly one-byte
>of
>>user-controlled
>>value, into the heap control-block. Depending on the robustness
>of the
>>application
>>in question, this may lead to an unrecoverable heap corruption
>>condition, causing
>>the application to terminate. In the case of Lsass.exe on WinXP-
>SP2, we
>>can crash
>>it locally after several iterations, from a less-privileged user,
>
>>causing a system
>>reboot. Vulnerable code although also exists in WinXP-SP1 but it
>does
>>not cause an
>>unrecoverable heap corruption in Lsass.exe.
>>
>>Vendor Affected:
>>Microsoft
>>
>>
>>Systems Affected:
>>========
>>WinXP-SP2 (DOS/Reboot)
>>WinXP-SP1 (minimal impact)
>>
>>
>>Exploitation:
>>=============
>>1) For local machine reboot via normal user account, on WinXP-SP2
>> OR
>> For remote machine reboot by enticing user to visit HTTPS site
>via IE,
>> on WinXP-SP2 (but over 2000 iterations required)
>>
>>
>>POC (crash-test/reboot):
>>========================
>>1) Run sctest.exe from a normal user account, on client machine
>> running WinXP-SP2.
>>
>>2) sctest.exe will attempt to use SChannel's SSL implementation
>to
>> parse pre-generated malformed SSL handshake records, over
>> several iterations, causing multiple off-by-one overwrites
>with
>> 0xFF byte, within the Lsass.exe process.
>>
>>3) Attach Debugger to Lsass.exe to see crash. The system will
>notify
>> the user and perform a 60sec. reboot count-down, after
>detecting
>> the Lsass.exe crash.
>>
>>** Lsass.exe crash-test can also be done by forcing/enticing
>Internet
>>Explorer
>> to access a HTTPS site, serving out the same malformed SSL
>handshake
>> records (as shown in source code below). However, over 2000
>iterations
>> are needed (IE needs to access HTTPS site over 2000 times),
>before
>>Lsass.exe
>> heap corruption occurs.
>>
>>
>>Vuln Analysis:
>>==============
>>(Based on schannel.dll/v5.1.2600.2180/WinXP-SP2)
>>The vulnerability exists in schannel.dll component, that
>implements the
>>SSPI-compliant
>>PCT/TLS/SSL protocol handling implementation. For more
>information on
>>SSPI and
>>how it relates to LSA, refer to
>>1)
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-
>us/secauthn/security/authentication_packages.asp
>>2)
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-
>us/secauthn/security/sspi.asp
>>
>>Essentially, in the case of SSPI authentication libraries like
>schannel,
>>kerberos, msv1_0 (ntlm),
>>data is exchanged between less-privileged user applications
>requring
>>authentication, and Lsass.exe.
>>With LSA providing the authentication back-end support. Both LSA
>and the
>>less-privileged application
>>communicate indirectly via the SSPI interface. Specifically, in
>SSL
>>authentication, untrusted SSL
>>record packets are passed from the less-privileged application to
>the
>>privileged LSA. While extensive
>>efforts are made in LSA to validate the SSL records, on WinXP's
>version
>>of schannel, an off-by-one
>>vulnerability exists in the parsing of the less-common and less-
>used SSL
>>server-key-exchange record.
>>The vulnerability can hence be triggered via less-privileged
>client
>>applications utilizing the
>>schannel's client-side SSL protocol implementation. This includes
>
>>Internet Explorer, whenever the user
>>uses IE to browse a HTTPS site.
>>
>>The vulnerable code exists in the _ReverseMemCopy() function and
>is
>>reachable from Ssl3ParseServerKeyExchange():
>>(via SPProcessHandshake()->PkcsGenerateClientExchangeValue())
>>
>>; On WinXP-SP1, the code below is located at 0x767FF976 (no
>symbols
>>available)
>>Ssl3ParseServerKeyExchange()
>>...
>>.text:767FFFC8 movzx ebx, byte ptr [esi] ;
>
>>MSB-byte of malformed signature length field
>>.text:767FFFCB movzx eax, byte ptr [esi+1] ;
>
>>LSB-byte of malformed signature length field
>>.text:767FFFCF shl ebx, 8
>>.text:767FFFD2 add ebx, eax
>>.text:767FFFD4 push ebx ;
>size=0
>>.text:767FFFD5 call _SPExternalAlloc@4 ;
>
>>HeapAlloc will return a valid 0-length heap buffer address
>>.text:767FFFDA test eax, eax
>>.text:767FFFDC mov [ebp+pbSignature], eax
>>.text:767FFFDF jz loc_768000B9
>>.text:767FFFE5 push ebx ;
>size=0
>>.text:767FFFE6 lea ecx, [esi+2] ;
>
>>address of the signature data in our malformed record
>> ;
>
>>containing 0xFF,0x41,0x41...
>>.text:767FFFE9 push ecx
>>.text:767FFFEA push eax ;
>
>>0-length heap buffer
>>.text:767FFFEB call _ReverseMemCopy@12
>> _ReverseMemCopy()
>> .text:767FF46F mov edi, edi
>> .text:767FF471 push ebp
>> .text:767FF472 mov ebp, esp
>> .text:767FF474 mov eax, [ebp+arg_8]
>> .text:767FF477 mov ecx, [ebp+arg_4]
>> .text:767FF47A push esi
>> .text:767FF47B mov esi, [ebp+arg_0]
>> .text:767FF47E lea eax, [esi+eax-1]
>
>>; EAX=0, ESI which points to 0-length heap buffer
>>
>
>>; is decremented to, before start of heap buffer
>> .text:767FF482 mov dl, [ecx]
>> .text:767FF484 mov [eax], dl
>
>>; Off-by-one overwrite with 0xFF from our signature data
>> .text:767FF486 dec eax
>> .text:767FF487 inc ecx
>> .text:767FF488 cmp eax, esi
>> .text:767FF48A jnb short loc_767FF482
>
>>; Just one-byte overwrite!
>> .text:767FF48C pop esi
>> .text:767FF48D pop ebp
>> .text:767FF48E retn 0Ch
>>
>>
>>Discovered by:
>>Steven
>>Security Researcher
>>Vulnerability Research Lab
>>COSEINC
>>
>>--
>>Thank you
>>Thomas Lim
>>COSEINC Private Limited
>>
>>-----BEGIN PGP PUBLIC KEY BLOCK-----
>>Version: PGP 8.1 - not licensed for commercial use: www.pgp.com
>>
>>mQGiBEQM9cARBADvlIe8Ck5/u2EtX3ikd/eKjI7uZKyIFHNLxEYBB1AaHmEvYCPi
>>VpvNr7ArKjbqlEpdsl6c9gQUY8vir5Lfk/p6siCD1aIYfCdPa64gKJQ66UVIUy7a
>>hIlE8sJ86mcbvVGzA4f1LjwPUPwymeKEQeDJyRLlRnPkxWzaoiZqHuEa/QCg/2/t
>>IAlQdVT7Q+ss51/NcL87RoEEANcf+ChnlH6vhXLSwnH1iXUMBbGA6t2F0/q29ROR
>>lsMoUQW5hvjuOw+4yDzGzmBDQUYbN0GI7pNOBs7UwerGOInTGCFD6nan0JpONT51
>>bp5sfF93PNH12I1qVFf+h/qdX4me2mhyKfSNvc0qQMydwfsCJ3vBbEWTF7CqWZFO
>>VadVA/9uJTKjJ7ZnN1enBBGUhLl6bA9estqH6lyP69B6Y1tGahDSqVyDe9Q9zs0T
>>XDcM6aS+PRnybzX9gfgPfSYtDzX3AU6C7N2XgSK5DnjVZVr2Tdd/2ttM7ApvzaeV
>>+ifO/nLGIQ38ik7mKlul5vlXsISShzHpUIdswuQtMp0R2sa+6bQfVGhvbWFzIExp
>>bSA8dGhvbWFzQGNvc2VpbmMuY29tPokAXQQQEQIAHQUCRAz1wAcLCQgHAwIKAhkB
>>BRsDAAAABR4BAAAAAAoJELxffA89J0fkz+cAn3cklzVq/VYiD9wgH0J2ULsuTbMl
>>AJ9NMdYJHBlunYjbPJIcRgGwhAkY4LkCDQREDPXAEAgA9kJXtwh/CBdyorrWqULz
>>Bej5UxE5T7bxbrlLOCDaAadWoxTpj0BV89AHxstDqZSt90xkhkn4DIO9ZekX1KHT
>>UPj1WV/cdlJPPT2N286Z4VeSWc39uK50T8X8dryDxUcwYc58yWb/Ffm7/ZFexwGq
>>01uejaClcjrUGvC/RgBYK+X0iP1YTknbzSC0neSRBzZrM2w4DUUdD3yIsxx8Wy2O
>>9vPJI8BD8KVbGI2Ou1WMuF040zT9fBdXQ6MdGGzeMyEstSr/POGxKUAYEY18hKcK
>>ctaGxAMZyAcpesqVDNmWn6vQClCbAkbTCD1mpF1Bn5x8vYlLIhkmuquiXsNV6TIL
>>OwACAggAwTip4JFx4LCDazFSyTG7qzIlZonEf3QTHNH4jP15CLvVFxjaHE8g2EgL
>>pt2+E6XDg7IGuZ2iXS9gwHkyLKzGR4bwpanAHyMZZbcQOglPHUkxuJZW+AjfcfOD
>>5jB+cUOtxk97ca/z9Fz+2qS8Q3sz2QSkHcZgBBxTS07cvd2P60ecVECBKG+dgxGw
>>X13e5hgw2tzFRMqnty66lKXYEIUj4ZSl70UPAmy5xUaU4EahLURN29f3zM+EPy72
>>374v28ud28yO59iyRqoUGiHr3c87wumrDtjwm8qKIkWHsi+7AiES29nCqtm4zN45
>>3yXkalvQ/O97ZJSinzZb851ToowyFIkATAQYEQIADAUCRAz1wAUbDAAAAAAKCRC8
>>X3wPPSdH5MLbAKCIYtkvUPIoxm15I4UlvCIZjT8hdACdEWiQKWdlwZCJTePk4CF9
>>swkS3cQ=
>>=Q3SR
>>-----END PGP PUBLIC KEY BLOCK-----
>
>--
>--
>"beepbeep it, i leave work, stop reading sec lists and im still
>hearing
>gadi"
>- HD Moore to Gadi Evron on IM, on Gadi's interview on npr, March
>2007.
>
>_______________________________________________
>Full-Disclosure - We believe in it.
>Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>Hosted and sponsored by Secunia - http://secunia.com/
--
Click for a second home mortgage, fast & free, no fees, approval today
http://tagline.hushmail.com/fc/CAaCXv1QbNMsbmnDafSnVJtW3sm0Gn5o/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists