RE: [fw-wiz] Vulnerability Response (was: BGP TCP RST Attacks)

From: Ben Nagy (ben_at_iagu.net)
Date: 05/21/04

  • Next message: Gwendolynn ferch Elydyr: "[fw-wiz] Re: Best Practices"
    To: <firewall-wizards@honor.icsalabs.com>
    Date: Fri, 21 May 2004 10:05:46 +0200
    
    

    Hm. Playing catch up, and ran across this.

    > -----Original Message-----
    > From: firewall-wizards-admin@honor.icsalabs.com
    > [mailto:firewall-wizards-admin@honor.icsalabs.com] On Behalf
    > Of Ahmed, Balal
    [...]
    > Microsoft targeted Exploits usually arrive on the scene 3 - 8
    > weeks after a vulnerability has been announced, this TCP RST
    > advisory cannot be looked at in the same light though as it
    > is cross platform/vendor.

    Oh it's way worse than that. The "full disclosure for $$$" crowd had working
    exploits for lsass within 24 hours (cf Dave Aitel's CANVAS announcement on
    full disclosure). Given how trivial it was to exploit I have no doubt that
    the underground had them around the same time. There was a widely publicised
    exploit for the RPC-DCOM stack overflow after 9 days. IIS SSL PCT - 8 days.
    Last year Workstation and Windows Messenger were around the same, but I
    can't be bothered doing the research for exact numbers. Remember that these
    are only the public exploits.

    Let me expand a little on this part first.

    There are a bunch of different vulnerability "classes". The simplest - a
    "stack based buffer overflow" is both very well understood, easy to exploit,
    and reliable. All of the major worms I can recall off the top of my head
    have been of this kind. We tend to see exploits for these really fast.

    More common recently are more complex vulnerabilities like the recent heap
    corruption bugs in various services, where it is downright HARD to either
    trace back the fault or to "seed" the heap to get even vaguely reliable
    exploitation. These are often not exploited in public at all, and the more
    you know about the exploitation process the less surprising this becomes.

    If you want an oversimplified yardstick - any vulnerability which is a
    stack-based overflow that yields remote SYSTEM should be addressed yesterday
    - there is less than 24 hours of safe time. This does not mean that you
    shouldn't patch _all_ vulnerabilities which are rated by the vendor as
    critical.

    > As stated elsewhere in this thread the largest threat vector
    > will be feeds from the Internet. Given that sasser exploited
    > a known vulnerability for which a patch was available, no
    > patch release from any vendor should be dismissed without due
    > process and risk analysis with buy in from security officers
    > and management. Its very easy to dismiss a vulnerability
    > without assessing the full impact until it is exploited by
    > which time its too late.

    I completely agree here.

    One trend I have heard of is security staff second guessing vulnerability
    advisories or vendor severity ratings - "Oh that's not exploitable". In
    general - don't do that. Even low-level memory management and architecture
    courses do nothing to prepare you for assessing real-world exploitability.
    This is partly because attack is easier than defence (and easier than
    understanding the theory) - an attacker doesn't care _why_ EIP is
    0x41414141. :)

    Another trend is "people" (also known as "they") claiming disingenuously
    that a vulnerability is not exploitable in order to taunt the vendor or
    whoever issued the advisory into giving more details. These "not
    exploitable" arguments can then be picked up by impressionable people, and
    taken as fact. Don't fall for it.

    > -----Original Message-----
    > From: firewall-wizards-admin@honor.icsalabs.com
    > [mailto:firewall-wizards-admin@honor.icsalabs.com] On Behalf
    > Of Josh Welch
    > Sent: 05 May 2004 16:24
    > To: firewall-wizards@honor.icsalabs.com
    > Subject: RE: [fw-wiz] BGP TCP RST Attacks (was:CIsco PIX
    > vulnerable to TCP RST DOS attacks)
    >
    > Mikael Olsson said:
    > <snip>
    > > I still believe that the #1 impact of this vulnerability,
    > as seen in
    > > an Internet-wide perspective, is killing BGP sessions in
    > core routers.[...]
    (Josh Welch)
    > The advisories I have seen have made this same statement.
    > However, according to another list I read there are a number
    > of network operators who feel this is not a real threat. A
    > number of them hold that it would be excessively challenging
    > to be able to match up the source-ip:source-port and
    > dest-ip:dest-port and effectively reset a BGP session without
    > generating a large volume of traffic, which should be noticed
    > in and of itself.

    The advisories are right. Those network operators are wrong. Surprise!

    OK, so here's my point. Assessing vulnerability exploitability is not some
    kind of "Oh yeah, sez who?" challenge. It is almost certain that the person
    telling you a vulnerability is critical has spent a lot more time looking at
    it then whoever is second-guessing the advisory. It is _strongly_ advisable,
    IMO, to err on the side of caution. I can think of three examples offhand
    where "they" cried "not real-world exploitable" and were completely wrong
    (ASN.1, BGP TCP RST, OpenSSH) and none, offhand, of the reverse case.

    Yes, I am completely aware that patching costs money, and remediation needs
    to be prioritised. Maybe vendors and researchers should do something more
    formal about also providing ease / reliability of exploitation data along
    with vulnerability information, but then everyone would think they were
    bragging and ignore it anyway.

    I'm going to go ahead and cut this short before it turns into a rant.

    Cheers,

    ben

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards


  • Next message: Gwendolynn ferch Elydyr: "[fw-wiz] Re: Best Practices"

    Relevant Pages