bugtraq - Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date: Tue, 10 Feb 2004 23:36:44 -0800
From: Sam Schinke <sschinke@...ealbox.com>
To: bugtraq@...urityfocus.com
Subject: 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@...ealbox.com