Date: Tue, 12 Jun 2007 15:21:56 -0500
From: ge@...uxbox.org
To: Thomas Lim <thomas@...einc.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com,
	dailydave@...ts.immunitysec.com
Subject: Re: Windows Oday release

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.

Powered by blists - more mailing lists