Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption
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@xxxxxxxxxxxxx