SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   OS (Microsoft)  >   Microsoft ASN.1 Library Vendors:   Microsoft
Microsoft ASN.1 Library Heap Overflows Let Remote Users Execute Arbitrary Code With SYSTEM Privileges
SecurityTracker Alert ID:  1009007
SecurityTracker URL:  http://securitytracker.com/id/1009007
CVE Reference:   CVE-2003-0818   (Links to External Site)
Date:  Feb 10 2004
Impact:   Execution of arbitrary code via network, Root access via network
Fix Available:  Yes  Vendor Confirmed:  Yes  
Version(s): Windows NT, 2000, 2003, XP
Description:   Several vulnerabilities were reported in Microsoft's ASN.1 library implementation. A remote user can execute arbitrary code with SYSTEM level privileges by exploiting any of a wide variety of services on the target system.

eEye Digital Security issued two separate advisories reporting flaws in the ASN.1 library implementation (MSASN1.DLL).

A remote user can reportedly overwrite heap memory and execute arbitrary code on the target system with SYSTEM level privileges. The flaw can reportedly be exploited by a variety of affected services, including Kerberos (UDP/88), Microsoft IIS using SSL, and NTLMv2 authentication (TCP/135, 139, 445).

According to eEye, the Microsoft ASN1 library contains many integer overflows.

These flaws affect Microsoft Internet Explorer, Outlook, and Outlook Express, as well as 3rd party applications that use certificates.

In their first advisory, eEye describes details of some flaws in the following decoder functions (but this is not an inclusive list):

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

In their second advisory, eEye describes a flaw that can be triggered by certain ASN.1 bit string values.

Microsoft has assigned these flaws a 'Critical' severity rating.

Derek Soeder is credited with discovery and Yuji Ukai is credited with performing additional research.

Impact:   A remote user can execute arbitrary code on the target system with SYSTEM level privileges.
Solution:   Microsoft has issued a fix.

Microsoft Windows NT Workstation 4.0 Service Pack 6a:

http://www.microsoft.com/downloads/details.aspx?FamilyId=92400199-B3D5-4826-98D4-F134849F5249&displaylang=en

Microsoft Windows NT Server 4.0 Service Pack 6a:

http://www.microsoft.com/downloads/details.aspx?FamilyId=E8315430-90CD-4B20-8F54-58527932B588&displaylang=en

Microsoft Windows NT Server 4.0 Terminal Server Edition Service Pack 6

http://www.microsoft.com/downloads/details.aspx?FamilyId=D83B39D3-FF13-4D0B-B406-A225AED0D659&displaylang=en

Microsoft Windows 2000 Service Pack 2, Microsoft Windows 2000 Service Pack 3, Microsoft 2000 Windows Service Pack 4:

http://www.microsoft.com/downloads/details.aspx?FamilyId=191853C4-A4D2-4797-A8C6-A2E663A53698&displaylang=en

Microsoft Windows XP, Microsoft Windows XP Service Pack 1:

http://www.microsoft.com/downloads/details.aspx?FamilyId=0CC30297-D4AE-48E9-ACD0-1343D89CCBBA&displaylang=en

Microsoft Windows XP 64-Bit Edition, Microsoft Windows XP 64-Bit Edition Service Pack 1:

http://www.microsoft.com/downloads/details.aspx?FamilyId=383C397F-9318-4AD5-9C2C-0577118A1E68&displaylang=en

Microsoft Windows XP 64-Bit Edition Version 2003, Microsoft Windows XP 64-Bit Edition Version 2003 Service Pack 1:

http://www.microsoft.com/downloads/details.aspx?FamilyId=FA280168-66E1-4B5F-958F-E178C3F61F7C&displaylang=en

Microsoft Windows Server 2003:

http://www.microsoft.com/downloads/details.aspx?FamilyId=3D7FFFF9-A497-42FF-90E7-283732B2E117&displaylang=en

Microsoft Windows Server 2003 64-Bit Edition:

http://www.microsoft.com/downloads/details.aspx?FamilyId=FA280168-66E1-4B5F-958F-E178C3F61F7C&displaylang=en

The computer must be restarted after you apply this security update.

Vendor URL:  www.microsoft.com/technet/security/bulletin/MS04-007.asp (Links to External Site)
Cause:   Boundary error

Message History:   This archive entry has one or more follow-up message(s) listed below.
Feb 13 2004 (Avaya Media Server is Affected) Microsoft ASN.1 Library Heap Overflows Let Remote Users Execute Arbitrary Code With SYSTEM Privileges
Avaya S8100/DefinityOne/IP600 Media Servers are affected by the Microsoft ASN.1 vulnerability (MS04-007).
Feb 13 2004 (Avaya Modular Messaging is Affected) Microsoft ASN.1 Library Heap Overflows Let Remote Users Execute Arbitrary Code With SYSTEM Privileges
Avaya S3400 Modular Messaging is affected by the Microsoft ASN.1 vulnerability (MS04-007).



 Source Message Contents

Subject:  Microsoft ASN.1 flaws


http://www.eeye.com/html/Research/Advisories/AD20040210.html

Microsoft ASN.1 Library Length Overflow Heap Corruption

Release Date:
February 10, 2004

Date Reported:
July 25, 2003

Severity:
High (Remote Code Execution)

Vendor:
Microsoft

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.).
This buffer overflow bug is within network management functions provided by the DCE/RPC 
service. These functions provide the ability to manage user accounts and network resources 
locally and remotely. Some network management functions generate a debug log file in the 
"debug" subdirectory located in the Windows directory.

A logging function implemented in WKSSVC.DLL is called to write entries to the log file. 
In this function, the vsprintf() routine is used to create a log entry. The string 
arguments for this logging function are supplied as parameters to vsprintf() without any 
bounds checking, so if we can pass a long string argument to the logging function, then a 
buffer overflow will occur.

We found some RPC functions which will accept a long string as a parameter, and will 
attempt to write it to the debug log file. If we specify a long string as a parameter to 
these RPC functions, a stack-based buffer overflow will happen in the Workstation service 
on the remote system. Attackers who successfully leverage this vulnerability will be 
executing code under the SYSTEM context of the remote host.

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.

Vendor Status:
Microsoft has released a patch for these vulnerabilities. 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

Related Links:
Retina Network Security Scanner - Free 15 Day Trial
http://www.eeye.com/html/Products/Retina/index.html

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-2003 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

---------------------------------------------------------------


http://www.eeye.com/html/Research/Advisories/AD20040210-2.html

Microsoft ASN.1 Library Bit String Heap Corruption

Release Date:
February 10, 2004

Date Reported:
September 25, 2003

Severity:
High (Remote Code Execution)

Vendor:
Microsoft

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).This buffer overflow bug is within network management functions provided by the 
DCE/RPC service. These functions provide the ability to manage user accounts and network 
resources locally and remotely. Some network management functions generate a debug log 
file in the "debug" subdirectory located in the Windows directory.

A logging function implemented in WKSSVC.DLL is called to write entries to the log file. 
In this function, the vsprintf() routine is used to create a log entry. The string 
arguments for this logging function are supplied as parameters to vsprintf() without any 
bounds checking, so if we can pass a long string argument to the logging function, then a 
buffer overflow will occur.

We found some RPC functions which will accept a long string as a parameter, and will 
attempt to write it to the debug log file. If we specify a long string as a parameter to 
these RPC functions, a stack-based buffer overflow will happen in the Workstation service 
on the remote system. Attackers who successfully leverage this vulnerability will be 
executing code under the SYSTEM context of the remote host.

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

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".

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

Protection:
Retina Network Security Scanner has been updated to identify this vulnerability.

Vendor Status:
Microsoft has released a patch for these vulnerabilities. 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!)

Related Links:
Retina Network Security Scanner - Free 15 Day Trial
http://www.eeye.com/html/Products/Retina/index.html

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-2003 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



 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, SecurityGlobal.net LLC