WARNING!!! Windows security issue

[Каскыр]

From: http://www.eeye.com/html/Research/Advis ... 40210.html

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.

Vendor Status:
Microsoft has released a patch for these vulnerabilities. The patch is available at:
http://www.microsoft.com/technet/securi ... 04-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

[Escaper]

А также:

MS04-005 - Title: Vulnerability in Virtual PC could lead to privilege elevation
MS04-006 - Title: Vulnerability in the Windows Internet Naming Service (WINS) Could Allow Code Execution
MS03-051 - Title: Buffer Overrun in Microsoft FrontPage Server Extensions Could Allow Code Execution

[Aka]

А также:

MS04-005 - Title: Vulnerability in Virtual PC could lead to privilege elevation
MS04-006 - Title: Vulnerability in the Windows Internet Naming Service (WINS) Could Allow Code Execution
MS03-051 - Title: Buffer Overrun in Microsoft FrontPage Server Extensions Could Allow Code Execution

а также тысячи им подобных на
support.microsoft.com
symantec.com
security.nnv.ru
void.ru
bagtraq.ru
google.com

[Каскыр]

Че щас будет-та...
http://www.microsoft.com/presspass/pres ... source.asp

[Бродяга]

Че щас будет-та...
http://www.microsoft.com/presspass/pres ... source.asp

Хе-хе. Ждем новую волну червей?

[Flying Hen]

Че щас будет-та...
http://www.microsoft.com/presspass/pres ... source.asp

Может, наконец, ее хакеры починят, чтобы не висла?

[Каскыр]

Че щас будет-та...
http://www.microsoft.com/presspass/pres ... source.asp

Может, наконец, ее хакеры починят, чтобы не висла?

Не, теперь будут искать кого засудить за то, что все кто угодно смогли убедиться, что "это не лечится"...

[Strannik223]

Так той во во, а где взять то можно?
Хотя боюсь что что бы разобраться прийдеться пол-жизни положить на это
Я когда Нетскейп свои исходники отдал на растерзание широким слоям населения попытался въехать, но пару дней спустя, после зникомством с кодом мой энтузиазм угас.

А вообще интересно, что произойдет раньше: МС опубликует свои исходники или перейдет на Линукс?