Re: EEYE: Microsoft ASN.1 Library Bit String Heap Corruption

[<bart2k () hushmail com>]

I for one am very grateful for the fact that eEye releases technical
information on the flaw.  I think it helps us ALL to know the technical
information so WE as security and IT professionals have a better idea
of what the real risk is.

I'm sorry but Microsoft Knowledge Base KB828028 tells me nothing of any
immediate value, plenty of web links to other advisories and documents
which will take me weeks to follow and read through before I know what
the heck they are patching and if it is truly a HIGH risk exposure for
my environment.  The eEye documents and other such providers of technical
documents are much better advisories at least that is MHO.



On Wed, 11 Feb 2004 06:22:20 -0800 Paul Tinsley <pdt () jackhammer org>
wrote:
> "Note: Due to the technical nature of the vulnerability described
> above,
> this advisory may contain disassembly and/or hexadecimal byte codes.
> This information is in no way related to "exploit code", "payloads",

> or
> "shell code"."
>
> *Phew*
>
> Sure am glad you put that notice in there, here I was getting all
> hot 
> and bothered that you were giving people a road map to the exploit.
>
> Here I was wondering why a security vendor would be increasing the
> risk 
> model by releasing details which will save the "bad guys" weeks
> of 
> research on the day of the patch release, giving the "good guys"
> even 
> less time to regression test this patch in their environment and
> >
> mitigate any harmful side effects.  Glad you could clear all that
> up for 
> us so that the "good guys" will feel all warm and fuzzy when they
> are 
> scrambling to get this patch deployed and working long hours when
> a worm 
> comes out before 100% patching could occur?
>
> Seriously, I think as a firm in the security industry that touts
> >
> themselves as an enterprise network protector you owe the community
> an 
> explanation as to what value the information in these bulletins
> have.  
> How many of your customers have been directly affected by worms
> which 
> have spawned from information you have provided?  What incentive
> is 
> there for corporations to fund a company which is causing them grief?
>
> What harm is there in waiting weeks/months after a patch release
> to give 
> such detail about a flaw?  Nothing in this bulletin helps me mitigate
> >
> this vulnerability, unless I am writing my own IDS rules to look
> for the 
> inevitable instance of verbatim hex traffic ending up in a worm
> down the 
> road.
>
> I am all for full-disclosure, but that doesn't have to mean immediate
> >
> disclosure, understanding the potential harm in what you are doing
> and 
> adjusting your ego boosting email release cycle to match it would
> do us 
> all some good.  Do I want you to stop releasing bulletins about
> >
> vulnerabilities?  No.  Do I want you to wait to release academically
> >
> valuable research info which might help others either avoid creating
> >
> such flaws in their code or find such flaws that already exist? 
> Yes. 
>
> Concerned Security Professional,
> Paul Tinsley
>
> ------
> Disclaimer:
>    Information and opinions contained within this message reflect
> my 
> personal views and should not be
>  construed as the opinions of companies I have affiliations with.
>
> Marc Maiffret wrote:
>
> > Microsoft ASN.1 Library Bit String Heap Corruption
> >
> > Release Date:
> > February 10, 2004
> >
> > Date Reported:
> > September 25, 2003
> >
> > Severity:
> > High (Remote Code Execution)
> >
> > Systems Affected:
> > Microsoft Windows NT 4.0
> > Microsoft Windows 2000
> > Microsoft Windows XP
> > Microsoft Windows Server 2003
> >
> > Description:
> > eEye Digital Security has discovered a second critical vulnerability
> in
> > Microsoft's ASN.1 library (MSASN1.DLL) that allows an attacker
> to
> > overwrite heap memory with data he or she controls and cause the
> > execution of arbitrary code.  ASN.1 is an industry standard used
> in a
> > variety of binary protocols, and as a result, this flaw in Microsoft's
> > implementation can be reached through a number of Windows applications
> > and services.  Ironically, the security-related functionality in
> Windows
> > is especially adept at rendering a machine vulnerable to this attack,

> > including Kerberos (UDP/88) and NTLMv2 authentication (TCP/135,
> 139,
> > 445).
> >
> > Technical Description:
> > Thanks to another pair of integer overflows, software that uses
> MSASN1
> > directly or indirectly is again vulnerable to a complete overwrite
> of a
> > large portion of its heap memory.  This time, the attack is specific
> to
> > bit string values (tags 03h and 23h), but the outcome is the same
> as
> > with the heap corruption involving large data lengths.
> >
> > To recap, ASN.1 BER encoding is a representation for binary data
> that
> > encapsulates pieces of that data into a hierarchy of typed values,
> >
> > analogous to "binary XML."  If a value consists of other values,
> then it
> > is considered constructed (or compound); if it contains only raw
> data,
> > then the value is described as simple.  The format of a BER-encoded
> > value is a tag number that gives the type and attributes of the
> value,
> > and then the length of the value data, followed by the data itself.
> If
> > bit 5 (20h) of the tag byte is set, this indicates that the value
> is
> > constructed, and MSASN1 will decode the following data as its own
> > BER-encoded block.
> >
> > In the case of a bit string, the first byte of data is the number
> of
> > bits (from 0 to 7) to exclude from the end of the bit string value
> data,
> > since the data is naturally given in bytes.  The remaining bytes,
> then,
> > contain the (8 * (value_length - 1) - number_of_unused_bits) bits
> that
> > compose the bit string.
> >
> > As the reader might guess, there's an interesting integer overflow
> here
> > when a bit string is given a length of one byte (only the "number
> of
> > unused bits" field, with no data bits following), and a non-zero
> number
> > of unused bits.  (We consider this an integer overflow, rather
> than a
> > signedness issue, because the number of bits is always treated
> as a
> > strictly unsigned value.)  ASN1BERDecBitString() and
> > ASN1BERDecBitString2() will both report that the length in bits
> of such
> > a bit string is (0 - number_of_unused_bits), a number that can
> fall in
> > the range 0xFFFFFFF9 (-7) to 0xFFFFFFFF (-1), although neither
> will
> > attempt to copy an amount of data based on this count.  The former
> > function will attempt to copy the length of the original data minus
> one
> > byte -- in this case, zero -- and doesn't hurt anything.  The latter
> > just returns a pointer into the original BER-encoded block and
> the
> > length in bits of the data, and is also harmless.
> >
> > While it's possible that some client application somewhere might
> misuse
> > this number of bits and create an exploitable condition, it doesn't
> > really matter because there's another integer overflow in MSASN1
> that
> > definitely will.  ASN1BERDecBitString() has a special way of handling
> > constructed bit strings (tag 23h), in that it concatenates each
> of the
> > simple bit strings that the compound one comprises.  By supplying
> a
> > valid constructed bit string that contains a single, simple bit
> string
> > with length 1 and 7 unused bits, a second integer overflow occurs
> while
> > adding the number of bits in the bit string to the cumulative total.
> > The following code from BERDecBitString() performs the vulnerable
> > arithmetic:
> >
> > 76195338  mov     eax, [ebp-18h]        ; = length of simple bit
> string
> > 7619533B  cmp     eax, ebx              ; (EBX = 0)
> > 7619533D  jz      short 7619539A        ; skip this bit string
> if empty
> > 7619533F  cmp     [ebp+14h], ebx        ; = no-copy flag
> > 76195342  jnz     short 761953AF        ; don't concatenate if
> no-copy
> > 76195344  mov     ecx, [esi]            ; = count of accumulated
> bits
> > 76195346  lea     eax, [ecx+eax+7]      ; *** INTEGER OVERFLOW
> ***
> > 7619534A  shr     eax, 3                ; div by 8 to get size
> in bytes
> > 7619534D  push    eax
> > 7619534E  push    dword ptr [esi+4]
> > 76195351  push    dword ptr [ebp-4]
> > 76195354  call    DecMemReAlloc         ; allocates a zero-byte
> block
> > If the first simple bit string encountered has a length of 0xFFFFFFF9
> > (-7) bits, then the arithmetic at 0x76195346 will add the total
> number
> > of accumulated bits (0), the length of the bit string being concatenated
> > (-7), and then an additional 7 for the purpose of rounding up,
> to arrive
> > at a total length of zero.  This sum is passed to DecMemReAlloc()
> to
> > allocate a zero-length heap block, but then the bit strings' original
> > lengths in [ESI] and [EBP-18h] are passed on to a function named
> > ASN1bitcpy() (not shown here), which in this case performs a typical
> > memcpy() and overwrites a whole bunch of heap memory as a result.
> >
> > To demonstrate this vulnerability, all that's necessary is a constructed
> > bit string with length 3, then a simple bit string with length
> 1 and an
> > unused bits field set to 7, all of which BER-encodes to the following
> > bytes:
> >
> > 23h/03h         ; constructed bit string (tag bit 5 = 1), length
> = 3
> > 03h/01h/07h     ; simple bit string, length = 1, 7 unused bits,
> no data
> > Normal Kerberos packets already have bit strings available, but
> to get
> > LSASS to accept a bit string within SPNEGO, it takes just a bit
> of
> > crafting.  If we provide a NegTokenInit token (tag A0h) containing
> a
> > ContextFlags value (tag A1h), then we can pass a bit string that
> does
> > get decoded using the vulnerable function.  (See RFC 2478 Section
> 3.2.1
> > for more details.)  This leaves us with the byte sequence below:
> >
> > A0h/09h         ; NegotiationToken: negTokenInit, length = 9
> > 30h/07h         ; sequence, length = 7
> > A1h/05h         ; reqFlags (ContextFlags), length = 5
> > 23h/03h         ; constructed bit string, length = 3
> > 03h/01h/07h     ; simple bit string, length = 1, 7 unused bits,
> no data
> > Note: Due to the technical nature of the vulnerability described
> above,
> > this advisory may contain disassembly and/or hexadecimal byte codes.
> > This information is in no way related to "exploit code", "payloads",

> or
> > "shell code".
> >
> > Protection:
> > Retina Network Security Scanner has been updated to identify this
> > vulnerability:
> > http://www.eeye.com/html/Products/Retina/index.html
> >
> > Vendor Status:
> > Microsoft has released a patch for this vulnerability. The patch
> is
> > available at:
> > http://www.microsoft.com/technet/security/bulletin/MS04-007.asp
> >
> > Credit:
> > Discovery: Derek Soeder
> > More Additional Research: Yuji Ukai (this guy rocks!)
> >
> > Greetings:
> > Dah and Murr; 14540253; fuzen; recurring thoughts, flashback humor,

> > deja-vu, and all the other sensations that go along with releasing
> > Windows advisories; people who read long advisories
> >
> > Copyright (c) 1998-2004 eEye Digital Security
> > Permission is hereby granted for the redistribution of this alert
> > electronically. It is not to be edited in any way without express
> > consent of eEye. If you wish to reprint the whole or any part of
> this
> > alert in any other medium excluding electronic medium, please e-
> mail
> > alert () eEye com for permission.
> >
> > Disclaimer
> > The information within this paper may change without notice. Use
> of this
> > information constitutes acceptance for use in an AS IS condition.
> There
> > are NO warranties with regard to this information. In no event
> shall the
> > author be liable for any damages whatsoever arising out of or in
> > connection with the use or spread of this information. Any use
> of this
> > information is at the user's own risk.
> >
> > Feedback
> > Please send suggestions, updates, and comments to:
> >
> > eEye Digital Security
> > http://www.eEye.com
> > info () eEye com
> >
> > _______________________________________________
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.netsys.com/full-disclosure-charter.html
> >
> >  
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html



Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
https://www.hushmail.com/services.php?subloc=messenger&l=434

Promote security and make money with the Hushmail Affiliate Program: 
https://www.hushmail.com/about.php?subloc=affiliate&l=427

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html