Bugtraq mailing list archives
Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption
From: Sam Schinke <sschinke () myrealbox com>
Date: Tue, 10 Feb 2004 23:36:44 -0800
Hello Marc, Tuesday, February 10, 2004, 12:47:29 PM, you wrote: MM> For example we setup a totally IPSEC secured network and we broke MM> into that network via our ASN bug which is called by the Kerberos. MM> We also have written exploits that take advantage of ASN via MM> NTLMv2 authentication. And the list goes on... How about evil ASN MM> SSL CERTs? Client or server? There is a menu a mile long for the MM> avenues of attacks that this thing can be used for. I think some of the advisories (not yours) relating to this issue are a very opaque to end users since they only mention "SSL" (US-CERT gets to this level of detail, MS limits itself to platforms). SSL is just YATA (Yet Another Tech Acronym) to most users. Further to that, I believe Microsoft is verging on negligence (and it's not the first time, IMO) by neglecting to mention these particular vulnerability details. In particular their asserting that a "server" is more likely to be "vulnerable". A server is certainly more likely to be vulnerable to unsolicited network traffic, but there are a number of ways for client systems to be impacted by this (eg, all of the client software you mention in your advisory). Yes, a remote, packet-based exploit is about as bad as it gets (unless the vulnerability also doesn't require a TCP handshake), but as your release mentions, Outlook Express is also vulnerable (So much for previewing signed email!). If MS is serious about getting people to patch, people need to be able to tell, at a glance, whether anything they actually USE is vulnerable. Listing the OS is great, but excluding very vulnerable client software is shoddy and implying that systems used as clients aren't "likely" to be vulnerable (in any way) is a lie. I guess we'll see yet another revised MS KB. Does anyone have a count on how many of their security KB's have been (ahem) "revised" in the past year or two? I seem to recall at least two or three that severely understated the impact of various issues (like this one), or that later required revised severity levels. -- Best regards, Sam mailto:sschinke () myrealbox com
Current thread:
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption, (continued)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Timothy J . Miller (Feb 12)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Florian Weimer (Feb 16)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Timothy J . Miller (Feb 12)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Rainer Gerhards (Feb 10)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Tina Bird (Feb 11)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Alun Jones (Feb 11)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Rainer Gerhards (Feb 11)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Steve Friedl (Feb 12)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Thor Lancelot Simon (Feb 13)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Buck Huppmann (Feb 16)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption David Wilson (Feb 16)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Sam Schinke (Feb 12)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Drew Copley (Feb 12)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Boyce, Nick (Feb 13)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Michael Shigorin (Feb 16)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Joshua Levitsky (Feb 16)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Bill Gallagher (Feb 15)