> -----Original Message-----
> From: Thomas Lim [mailto:thomas@xxxxxxxxxxx]
> Sent: Tuesday, June 12, 2007 10:58 PM
> To: full-disclosure@xxxxxxxxxxxxxxxxx;
> bugtraq@xxxxxxxxxxxxxxxxx; dailydave@xxxxxxxxxxxxxxxxxxxxx
> Subject: Windows Oday release
>
> dear all
>
> 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)
>
> us/secauthn/security/authentication_packages.asp
> 2)
>
> 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-----
>
>
