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

From: Marcus J. Ranum (mjr_at_ranum.com)
Date: 05/28/04

  • Next message: ArkanoiD: "[fw-wiz] certificate management requirements" 
    To: "Ben Nagy" <ben@iagu.net>
Date: Fri, 28 May 2004 12:19:22 -0400

    Ben Nagy wrote:
    >mjr writes:
    >> I don't think patch management is the solution for any
    >> significant aspect of the problem. I know that flies in the
    >> face of the "common wisdom" of security these days, but I
    >> think eventually time will tell and we'll give up on patch
    >> management as a security technique. [...]
    >
    >If I stood on top of a very large building with a hundred foot stack of
    >Marshall amps and used the entire building as a pre-amp and subwoofer, I
    >still could not yell "CRAP!" loud enough.

    As I said, I think time will tell. :)

    <RANT>

    Come on, Ben! Join me in challenging the preconceptions of an
    industry that has grown up around "if you can't do something RIGHT
    do something STUPID, HARDER!" That's what we're talking about,
    here, with all the focus on patch management:
    - Rather than run a good O/S: run a bad one and MANAGE it BETTER
    - Rather than understand your connectivity: leave it OPEN and FIDDLE WITH
            your endpoints CONSTANTLY
    - Rather than run good code: run bad code and UPGRADE IT DAILY

    Talk about not being able to yell "CRAP" loud enough?? What's
    wrong with this picture?!?!

    >Take a look at the recent security record of MS RPC endpoints. You can't
    >turn them off. You can't secure them. Windows will break.

    Yes. So? YOU ARE INSANE IF YOU ARE RELYING ON WINDOWS
    FOR INTERNET-FACING CRITICAL SYSTEMS.

    Of course at this point everyone chimes in and says, "BUT WE HAVE TO!"
    for (whatever) reason(s). Well, then don't complain that it sucks. But
    don't expect to be able to make it not suck through dint of sheer
    effort. That's not gonna happen, either.

    We have seen - CLEARLY - with software and O/S in general - that
    they are not reliable enough to provide a solid security platform. The
    evidence is manifest; it's been staring us in the face for at least the
    last 10 years and it's been covered in big, blinky neon signeage for
    the last 4 years. Everyone would rather be in denial.

    What do you think? If we install JUST ONE MORE PATCH it's gonna
    be SECURE? Heck, no. The only way to secure this crap is to hold
    it down and hammer a stake through its heart.

    </RANT>

    >How _ELSE_ do you want to deal with that problem? Let me put it a different
    >way. However much you lock down machines, your biggest remaining worry will
    >be software vulnerabilities in the services you _do_ run - the rest is just
    >a matter of degrees. How do you eliminiate vulnerabilities? Patch.

    Ok... now let me catch my breath and we can talk sense... ;)

    You're absolutely right that the software vulnerabilities in services are
    what will kill you. That's why the old-school doctrine was:
            - collapse access down to services
            - collapse services down to a handful of trusted servers for those services
            - make the service implementations on those trusted servers as well-configured
                    as possible
            - use mitigation techniques to surround those services (setuid, chroot,
                    noexec, append-only, tamper-detection, app proxies, default
                    deny) wherever possible and to the highest extent practical
            - deny all else

    There are a few people on this list (Hi Fred, Paul!) who have been singing
    this song for a very very long time. We don't sing it because it's fun and
    we like the sound of our voices - we sing it because it's the only way we
    know to come close to reliably producing good results. It doesn't
    GUARANTEE good results - but it's close to reliable.

    The other approach is:
            - we want to make everything accessible to everything else
            - we know our software sucks
            - we can't secure everything
            - so we'll try to automate the process of securing whatever is
                    particularly unpleasant right now

    >> Put differently, I see the "patch it everyplace" approach as
    >> an over-extension of an approach that *did* work OK:
    >> policy-centric host hardening.
    >
    >You can only harden up until the OS will let you.

    Well, yeah. If you're using the wrong OS you're an idiot. The fact that
    there are a lot of idiots out there doesn't make them any less idiotic, either.
    Let me see here: "I am gonna build a 'bastion host' on an O/S that doesn't
    have chroot, or any notion of file permissions or execution control. But
    I like it because it automatically loads device drivers on demand and it
    has shared libraries and no CHANCE of producing a statically bound
    executable and by the way anyone can overwrite a shared library any time
    they get file level access because there are no file permissions enforced."
    That sound smart to you? Thats like saying "I am going to build the
    Eiffel Tower out of toilet paper because I like how soft toilet paper is!"
    ;)

    > If the core service has an
    >exploitable bug then only a patch will fix it.

    Yes. But.

    First off, the big mistake a lot of folks make is that the place the
    underlying code of a service where it's exposed to untrusted access.
    I can't avoid saying "I told you so!" when I see that "application security"
    is now a HOT TOPIC (again) - why? Because it's STUPID to, for example,
    expose an Exchange server to the Internet when you can expose a
    trusted piece of minimized code that runs in a locked-down environment.
    Yes, Postfix has needed security patches. But has it needed as many
    as Exchange? Yes, smap has needed a security patch (one, once, but
    it was because it was linked against syslog()) but has it needed as many
    as Exchange? In either case, the failure modes of both - running chrooted
    and setuid nobody - are infinitely preferable to the failure modes of the
    other approach.

    The idea that code needs to be patched frequently and often is
    predicated on the flawed concept that cruddy code is exposed to
    untrusted network. That's just dumb. The fact that lots of people
    do it, and lot of people want to do it, doesn't make it one iota
    less dumb. The fact that lots of security practitioners aid and abet
    the dumbness by preaching "patch! patch! patch!" makes them
    willing participants in the dumbness. Fight back. Fight dumbness.
    Come over to the light. Turn away from the darkness. Fight the
    "accepted wisdom" of defeat. Use The Force, Ben.... ;)

    > Other solutions (like my
    >famous "marketing" host based vulnerability mitigation ;) might save your
    >backside for a while, but the real intent of those solutions is to buy you
    >time, not obviate the need to fix the real problem.

    Exactly!! Put another way - the intent of those solutions is to
    make it easier for you to survive doing something stupid that
    you may not survive anyhow.

    >Even assuming that you could have pre-hardened a box (it is true that
    >hardening _might_ have let you dodge Blaster and Sasser, but wait until the
    >multiple vectored worms really start hitting us)

    I have never had a worm or virus since I got interested in security.
    NEVER. And I use Windows as my primary desktop platform,
    so it's not that I'm a UNIX bigot. I have no idea why other people
    seem to accept them as a fact of life. Accept dumbness, more like.

    > then most people just won't
    >do it. In any case, having a huge freaking gaping security hole in a core
    >service is not something I feel comfortable about, same as running a
    >thousand Win95 boxes "behind a firewall" sends shivers down my spine.

    Depends on the firewall and the services it's letting through. That
    kind of thing can be controlled with tight policies, service-centric
    segmentation, server-centric subnets, and desktop A/V. This is
    not rocket science. It's just not WHAT PEOPLE WANT. They
    want to accept dumbness and let those Windows boxes get to
    Instant Messenger, Peer-to-peer file sharing, remote control
    desktop, and dancing animated pigs that run on their desktops.
    They want dumbness.

    >It may be just me, but it sounds like you are arguing that people's
    >mainstream desktop OSes should be something that can be easily hardened on a
    >service-centric basis, understand true user / kernel / virtualisation
    >separation and yet have full enterprise functionality.

    No, I think networks need to be segregated into roles, access needs
    to be mediated on a service level and minimized. Yes, desktops
    that are vulnerable to malcode should have malcode protection
    (my desktop AV clobbers about 1 or 2 viruses a week that get
    through my spam filters and attachment blockers) and core
    services that are mission critical need to be run on real operating
    systems not glorified program loaders which were designed to
    appeal to dummies.

    >If anybody else advanced this theory I would snort milk through my nose.

    I'd pay to watch that!!!!!!!

    >With you I will just say that you are five years ahead of your time.

    What?? I've been saying EXACTLY THE SAME THING since
    1990.

    *BUT* Peter Neumann has been saying EXACTLY THE SAME THING
    since 1963 or thereabouts. I was 1 year old then.

    Dude, I'm not "advanced" I'm "retro" !!!! :)

    >I am
    >100% behind you as an idealist, but, as a professional, I don't see that as
    >useful right now. :D

    Because you're stuck in the dumbness. When you're up to your
    neck in wet horse manure and you've got a shovel in your hand,
    it's hard to think about just getting out of the manure and going
    someplace else. After all, you've got a perfectly good shovel,
    and the next shovel load might be the one that turns the tide...

    Keep shovelling,
    mjr.

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

  • Next message: ArkanoiD: "[fw-wiz] certificate management requirements"

    Relevant Pages
    • Quantcast