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

From: Sam Schinke (sschinke_at_myrealbox.com)
Date: 02/11/04

  • Next message: please_reply_to_security_at_sco.com: "OpenLinux: slocate local user buffer overflow" 
    Date: Tue, 10 Feb 2004 23:36:44 -0800
To: bugtraq@securityfocus.com

    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
  • Next message: please_reply_to_security_at_sco.com: "OpenLinux: slocate local user buffer overflow"