| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 13 Jun 2007 20:42:10 +0530 From: "crazy frog crazy frog" <i.m.crazy.frog@...il.com> To: joey.mengele@...hmail.com Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com, thomas@...einc.com, ge@...uxbox.org, dailydave@...ts.immunitysec.com Subject: Re: Windows Oday release dear all, thanks for this nice thread. --------------------------------------- http://www.secgeeks.com get a blog on SecGeeks :) register here:- http://secgeeks.com/user/register rss feeds :- http://secradar.com/node/feed http://www.newskicks.com Submit and kick for new stories from all around the world. On 6/13/07, Joey Mengele <joey.mengele@...hmail.com> wrote: > 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/ > -- --------------------------------------- _______________________________________________ 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