Re: Windows Oday release

["crazy frog crazy frog" <i.m.crazy.frog () gmail com>]

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 () hushmail 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 () linuxbox 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/