Microsoft Sits on Security Flaw for Six Months

http://www.eeye.com/html/Research/Advisories/AD20040210.html ^ | 2/10/2004 | eEye

[N3WBI3]

Preamble: We wanted to write another "Night Before Xmas" poem but the vendor missed the last few release dates, so we had to resort to some MC(SE) Hammer:

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

[Prime Choice]

Gotta love the guys at eEye for the sense of humor. : )

[drlevy88]

bushyboy, how often does linux sit on a security bug for 6 months

[TechJunkYard]

From the advisory:

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

The MSASN1 library is fraught with integer overflows... 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.

(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().)

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.

At MS, crappy coding is job 1. Looks like they're just gonna have to go back to doing CODE REVIEWS, eh?

[Bush2000]

At MS, crappy coding is job 1. Looks like they're just gonna have to go back to doing CODE REVIEWS, eh?

Oh, yeah .. because, God knows, open source code is flawless and doesn't suffer from buffer overflows ... /SARCASM

[TechJunkYard]

... open source code is flawless and doesn't suffer from buffer overflows...

You said it... I didn't.

[Bush2000]

You said it... I didn't.

And if you took it as anything but sarcasm, you need psychiatric treatment.

[drlevy88]

That something slipped past the original programming team is no big surprise. That microshaft took 6 months to fix this (by what grandiose effort? -- programming in a sanity check!) is inexcusable. I bet they didn't want to rush out that sanity check because it would have caused other things to fail that "depended" on the bug!

[TechJunkYard]

You are the only FReeper who even says that kind of thing anymore. You know it's false and we know it's false. Thus, it is an inappropriate "defense" (if even that) in a discussion of Microsoft design flaws, particularly in the wake of the famous "Trustworthy Computing Initiative".

Get off it already.

[adam_az]

Oh, yeah .. because, God knows, open source code is flawless and doesn't suffer from buffer overflows ... /SARCASM</>

Can you point out any buffer overflow bugs in popular open source software that took 6 months to be fixed?

[adam_az]

Oh, yeah .. because, God knows, open source code is flawless and doesn't suffer from buffer overflows ... /SARCASM</>

Can you point out any buffer overflow bugs in popular open source software that took 6 months to be fixed?

[Bush2000]

Who gives a rat's ass? This is a LAN-only attack.

[adam_az]

Who gives a rat's ass? This is a LAN-only attack.

What are you talking about? All of the things below can be done over routed TCP/IP connections.


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



I'll add this to the ever growing list lf B2K doozies. ;)

[adam_az]

Still waiting for your response, sharpie.

[Bush2000]

Kerberos (UDP/88)

LAN-only. No enterprise is going to leave Kerberos authentication exposed over the Web.

Microsoft IIS using SSL

This is hypothetical only.

NTLMv2 authentication (TCP/135, 139, 445)

LAN-only. No enterprise is going to leave NTLM ports exposed over the Web.

[Bush2000]

And before you pull the usual hit-and-run BS, try running this query: http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=ASN.1+Vulnerability+and+SSL

Imagine my shock and horror to discover that ... GASP ... ASN.1 remote exploits also existed in ... OpenSSL and the usual open source crap, etc.

[adam_az]

IIS using SSL is not a hypotheitcal vector, it's a service that relies on the vulnerable resource. It's a real vector.

As for the others, I've done intrusion testing for a fairly llarge number of Fortune 500 orgs, and have encountered exposed NTLM and Kerberos ports for all of them.

Microsoft even recommends portscanning your own MS systems daily!
http://www.microsoft.com/serviceproviders/columns/isp_security.asp

Of course, someone could always break into a network and penetrate the firewall using countless other techniques, then use this bug to pop boxes once inside the perimiter.

Why are you going out of your way to minimize the impace of this vulnerability? It is real, and it is serious.

[adam_az]

"http://www.microsoft.com/serviceproviders/columns/isp_security.asp"

Um.

Don't make me dig up all the threads where you lost and which you then abandoned. I don't hit and run on this forum, and I don't BS. I can back up what I say, unlike you.

BTW, the ASN.1 OpenSSL but is TOTALLY different than the MS bug. They aren't the same implementation. The codebase is different. All they have in common is that they are both implementation errors of ASN.1, which is a formal notation used for describing data transmitted by communication protocols. As usual, you miss the point because you don't understand the technical details.

Additionally, OpenSSL folks didn't sit on the bug for 6 months before fixing it like MS did. ;)

Also, you claimed it wasn't a serious bug, but MS rates it as CRITICAL. I'll take Microsofts word over yours, even if they were negligent in fixing it.

[Bush2000]

IIS using SSL is not a hypotheitcal vector, it's a service that relies on the vulnerable resource. It's a real vector.

And yet, oddly enough, you can't produce code that exploits it.

As for the others, I've done intrusion testing for a fairly llarge number of Fortune 500 orgs, and have encountered exposed NTLM and Kerberos ports for all of them.

Then your customers are morons. This is a LAN-only attack. Most enterprises are saavy enough to know that you can't leave these ports open. If some enterprise leaves them open, it's like leaving the front door unlocked after hours. They deserve what they get.

[Bush2000]

BTW, the ASN.1 OpenSSL but is TOTALLY different than the MS bug. They aren't the same implementation. The codebase is different.

Irrelevant. Both attacks involve a remote exploit.

Additionally, OpenSSL folks didn't sit on the bug for 6 months before fixing it like MS did. ;)

So what. You weren't waiting on anyting: You only became aware of the vulnerability yesterday.

Also, you claimed it wasn't a serious bug, but MS rates it as CRITICAL. I'll take Microsofts word over yours, even if they were negligent in fixing it.

Please point out where I said that it wasn't a serious bug?