Re: << Security bulletin 04-006 WINS security issue [yup that affects us pretty much]

From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] (sbradcpa_at_pacbell.net)
Date: 02/11/04 

Date: Tue, 10 Feb 2004 19:23:10 -0800

1. Don't depend on the firewall.
2. They are coming through your firewall because you may allow it

Affects Kerberos, NTLMv2 authentication, and applications
that make use of certificates (SSL, digitally-signed e-mail, signed
ActiveX controls, etc.).

DO NOT depend on just your firewall. It is MERELY a speedbump.

PATCH.

Message: 8
Date: Tue, 10 Feb 2004 10:30:43 -0800
From: "Marc Maiffret" <mmaiffret@eeye.com>
To: <full-disclosure@lists.netsys.com>
Subject: [Full-Disclosure] EEYE: Microsoft ASN.1 Library Bit String Heap
Corruption

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

--__--__--

Message: 9
Date: Tue, 10 Feb 2004 10:30:47 -0800
From: "Marc Maiffret" <mmaiffret@eeye.com>
To: <full-disclosure@lists.netsys.com>
Subject: [Full-Disclosure] EEYE: Microsoft ASN.1 Library Length Overflow
Heap Corruption

Microsoft ASN.1 Library Length Overflow Heap Corruption

Release Date:
February 10, 2004

Date Reported:
July 25, 2003

Severity:
High (Remote Code Execution)

Systems Affected:
Microsoft Windows NT 4.0 (all versions)
Microsoft Windows 2000 (SP3 and earlier)
Microsoft Windows XP (all versions)

Software Affected:
Microsoft Internet Explorer
Microsoft Outlook
Microsoft Outlook Express
Third-party applications that use certificates

Services Affected:
Kerberos (UDP/88)
Microsoft IIS using SSL
NTLMv2 authentication (TCP/135, 139, 445)

Preamble:

We wanted to do another Night Before Xmas but the vendor missed the last
few release dates, so we had to resort to our MC(SE).

U Can't Trust This
By: MCSE Hammer

Blaster did ya some harm
We just say, hey, another worm
But thank you, for trusting me
To mind your site's security
It's all good, when your server's downed
Our dope PR will pass blame around
Cuz it's known as such
That this is some software, you can't trust

I told ya Homeland
U can't trust this
Yeah that's why we're giving ya the code
U can't trust this
Check out eEye, man
U can't trust this
Yo let 'em bust more funky system
U can't trust this

Give 'em a string or recvfrom
Like no sweat they got the keys to your kingdom
Now ya know
You talk about eEye, you're talking about holes
Remote and tight
Coders still sweating so someone better write
A book to learn
What it's gonna take in '04
To earn some trust
Legit, either secure or ya might as well quit

That's the word because you know
U can't trust this
U can't trust this

Breakin' in

Stop -- eEye time

Description:
eEye Digital Security has discovered a critical vulnerability in
Microsoft's ASN.1 library (MSASN1.DLL) that would allow an attacker to
overwrite heap memory on a susceptible machine and cause the execution
of arbitrary code. Because this library is widely used by Windows
security subsystems, the vulnerability is exposed through an array of
avenues, including Kerberos, NTLMv2 authentication, and applications
that make use of certificates (SSL, digitally-signed e-mail, signed
ActiveX controls, etc.).

Technical Description:
The MSASN1 library is fraught with integer overflows. In this advisory,
we'll describe a pair of arithmetic errors in a generic and low-level
part of ASN.1 BER decoding that allow a very large swath of heap memory
to be overwritten. This vulnerability affects basically any client of
MSASN1.DLL, the most interesting of which are LSASS.EXE and CRYPT32.DLL
(and therefore any application that uses CRYPT32.DLL).

Although the specifics of ASN.1 BER encoding are beyond the scope of
this advisory, the basic idea is that it's an encoding scheme for
flexibly representing binary data, and is often compared to "binary
XML." Each piece of data is encoded as a typed value, which is
constructed as a tag number that describes how to interpret the
following value data, then the length of the data, and finally, the data
itself. This length field is the subject of our advisory. By supplying
a very large value (from 0xFFFFFFFD to 0xFFFFFFFF) in this field, we can
cause an integer overflow in a heap allocation routine, and although
there are checks in place to ensure the validity of a value's length, a
separate pointer arithmetic overflow in the verification routine gives
rise to the vulnerability. Here's how:

1. When a simple value (a value that consists of atomic data, rather
than more values) is decoded by MSASN1, ASN1BERDecLength() is called to
retrieve the length of the value, then passes the reported length to the
ASN1BERDecCheck() function to make sure that that much data actually
exists.

2. ASN1BERDecCheck() verifies that (pointer_to_start_of_data +
reported_length_of_data), unsigned, is less than or equal to
(pointer_to_start_of_BER_block + total_size_of_BER_block). If not, the
function returns failure, which propagates back up the call stack and
causes decoding to stop. (As an aside, it's interesting to note that
this vulnerability was silently fixed in Windows 2000 SP4 and Windows
Server 2003, due to an additional comparison being included in
ASN1BERDecCheck().)

3. If the function that called ASN1BERDecLength() then attempts to
allocate memory and make a copy of the data (e.g.,
ASN1BERDecOctetString(), but not the ASN1BERDecOctetString2() variant),
it will then pass the decoded length to DecMemAlloc(), which rounds the
length up to a DWORD multiple and then attempts to allocate the result.
The operation of this function can be represented as
"LocalAlloc(LMEM_ZEROINIT, (length + 3) & ~3)."

4. If DecMemAlloc() succeeds, the calling function then memcpy()'s the
value data into the allocated heap buffer, using the original decoded
length of the value as the byte count.

If a very large length is decoded by ASN1BERDecLength() in step 1, then
there will be an integer overflow when ASN1BERDecCheck() adds the length
to the current data pointer in step 2, essentially causing the resulting
pointer to "wrap around" the 32-bit address space and therefore have an
address that is numerically less than the pointer to the end of the
buffer.

Now, to be more specific, if a length in the range 0xFFFFFFFD through
0xFFFFFFFF is given, it will pass through ASN1BERDecCheck() with no
problem, and then something really bad happens. Because of the
round-off in DecMemAlloc(), the three lengths in this range will all
round "up" to zero. LocalAlloc() successfully allocates a zero-length
heap block whose address gets returned to the caller, but then the
original, very large length is handed to memcpy(). The result is a
classic, complete heap overwrite, where all contiguous heap memory
following the zero-length block is wiped out by arbitrary data.

The simplest way to manifest this condition is to encode a simple octet
string (tag 04h) with a length-of-length set to 4 and a length of
0xFFFFFFFF, which corresponds to the bytes 04h/84h/FFh/FFh/FFh/FFh.
Depending on which decoder functions the MSASN1 client uses, it is also
possible to leverage this vulnerability through OIDs and character
strings as well. The following is a sampling of vulnerable decoder
functions:

ASN1BerDecCharString
ASN1BERDecChar16String
ASN1BERDecChar32String
ASN1BERDecEoid
ASN1BERDecGeneralizedTime
ASN1BERDecMultibyteString
ASN1BERDecOctetString
ASN1BERDecOpenType
ASN1BERDecSXVal
ASN1BERDecUTCTime
ASN1BERDecUTF8String
ASN1BERDecZeroCharString
ASN1BERDecZeroChar16String
ASN1BERDecZeroChar32String
ASN1BERDecZeroMultibyteString

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
Additional Research: Yuji Ukai

Very Special Thanks:
Yuji Ukai, again, for the majority of "The Menu"
Steve Peters and Shawn O'Donnell for extreme ASN.1 (BER!) and
certificate lore

Greetings:
DDDDDD; GM-TX, BMNN-FL, JKP-FL, NV-TX; Heather & Heather; all the coffee
shop folks; 214; and always, every last one of the eEye crew

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

Douglas McIver wrote:
> I am curious how it can attack my network if I have everything behind a
> firewall with the exception of port 25 open for SMTP traffic?
>
> Don't worry, I am going to deploy it, just trying ot understand how exactly
> it is supposed to penetrate my network.
>
> Thanks,
> Douglas
> "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com> wrote in message
> news:e0cajBE8DHA.3704@tk2msftngp13.phx.gbl...
>
>>Everything like this eventually gets to WU, but I would recommend that you
>>manually obtain a copy of this set of patches (MS04-007 particularly) and
>>move as quickly as possible to get these patches in.
>>
>>MS04-007 deserves putting on a floppy and walking to every machine you
>
> have
>
>>immediately if you have no faster way to deploy it. Get my drift??
>>
>>
>>"Trevor OE News" <thetrev68 @ hotmail.com> wrote in message
>>news:%23Gv7eQA8DHA.2572@TK2MSFTNGP09.phx.gbl...
>>
>>>Will these show up in windowsupdate, or do I need to download them
>>>seperately?
>>>
>>>-Trevor
>>>
>>>"Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]" <sbradcpa@pacbell.net>
>>>wrote in message news:OZztSKA8DHA.2952@TK2MSFTNGP09.phx.gbl...
>>>
>>>>MS04-006
>>>>Vulnerability in the Windows Internet Naming Service (WINS) Could
>
> Allow
>
>>>>Code Execution (830352)
>>>>http://www.microsoft.com/technet/security/Bulletin/MS04-006.asp
>>>>
>>>>
>>>>--
>>>>http://www.sbslinks.com/really.htm
>>>>
>>>
>>>
>>
>
> 

-- 
http://www.sbslinks.com/really.htm

Relevant Pages