Slashdot Mirror


Firewall + Censorware = Trouble

Is your company thinking of buying a firewall that comes bundled with blocking software? Think twice. SecurityFocus ran thisstory earlier this week: "Censorware gaffe turns 'World's Most Secure Firewall' into an open door." Turns out that bundling Cyber Patrol with Network Associates' Gauntlet meant creating a custom server that "contains a buffer overflow bug, and, further, mistakenly accepts connections from the outside world" - so intruders could get root on the firewall. Makes sense to me: firewall designers keep security uppermost in mind; censorware designers don't. Update 8:55 AM: BusinessWeek is calling it "The Breach That's Shocking the Firewall Industry."

4 of 72 comments (clear)

  1. Binary poison. by Spudley · · Score: 5

    This proves the point about adding complexity to a system.

    The most secure systems are generally speaking, the simplest. It should be obvious that the fewer things a system has to do, and the fewer ways of doing those things, the less chance there is for there to be a security hole (or any other kind of flaw).

    Obviously, some for applications it's better to have some 'more-than-one-way-to-do-it'. Firewalls do not fall into this category.

    A Firewall should be there for one purpose, and one purpose only: to control access to a network. Adding features like cyberpatrol was asking for trouble. If you want cyberpatrol software, install it seperately, behind the firewall, so that they can't interfere with each other.

    --
    (Spudley Strikes Again!)
  2. Its about complexity, not censorware by tmu · · Score: 5

    It's unfortunate that this issue is going to be confused by the fact that the censorware caused it. This will leave many network administrators with the impression that as long as they are not doing content-based filtering or blocking, they're ok.

    In fact, this is the first remote-root exploit in a commercial firewall in a long time and it is due entirely to the fact that commercial vendors are under pressure by the market to throw the damned kitchen sink into their products. Firewalls need to be simple enough to be auditable. Simple enough to be understandable by a human at a time and place by herself.

    Commercial firewalls like Checkpoint's FW1 and Gauntlet (among many other offenders) are selling like hotcakes for bad reasons. Smart organizations are implementing simpler solutions like OpenBSD-based ipfilter (Darren Reed's well-tested stateful packet filtering running on Theo Raadt's well-audited kernel). They are then (as other folx have suggested) supplementing with things like squid for proxying (and hopefully on a box separate from the firewall!) and even still using things like the TIS toolkit (now from NAI but originally authored by Marcus Ranum. Smart organizations run secure MTAs like qmail and do virus filtering on the mail server only if they have to (it's a task better taken care of at the client, IMHO).

    These are not fancy tools, but they perform their objectives simply enough that they can be trusted.

    Security should not be about features, ever. It should be about verifiability and trustworthiness.

  3. Would this be newsworthy if... by Glowing+Fish · · Score: 5

    This had not been a censorware product that caused the security hole? This doesn't seem to be a major security hole, it is confined to one specific firewall and one particular censorware product.

    If Slashdot is trying to show a technical flaw, that is cool. And if Slashdot is trying to say that censorware is wrong\unethical, that is also okay. But by combining the two, what Slashdot seems to be subliminally implying is:

    "Unethical" software is inherently techincally flawed.

    Of course, no one would come out and say that, because it is totally ridiculous. But by showing examples, the idea is implanted.

    --
    Hopefully I didn't put any [] around my words.
  4. Bugs happen. But Trialware In The Firewall?!? by Effugas · · Score: 5

    Actually, it's just an unfortunate coincidence that of all the various things that could have gone wrong with this Firewall, it was the bridge to the Censorware app that did. As Schneier argues, excess complexity really is the death of security, and the bottom line was that an app intended to filter packets had detailed, layer 7 filtering hoisted onto it through a hack, rather than a chosen design. It doesn't matter what was hacked in--something was hacked, it wasn't thought out well enough, and it went boom.

    It's just a rather inconvenient failure for the Censorware industry that it was one of theirs that took the system down.

    But there's a much more interesting failure, one that I don't really think has been paid enough attention to: It's not that Gauntlet had a security breach, it's that the breach came from 30-Day Trialware installed by default on a mission critical service.

    If an app I choose to install turns out to have a hole, I'm more than willing to give the authors time to repair the hole. But if an app I *don't* choose to install turns out to install some other app with a hole, one I didn't realize would be installed by default, didn't realize would by default communicate my download logs to the central office(Hi Realnetworks! How's that Download Demon doing?), didn't realize was being shoved on me as a supposed freebie but as an actual privacy and security disaster...

    Then the honesty that underlies every commercial reaction gets toasted.

    I don't blame the coders for having a bug in their bridge code. I blame the policymakers for specifying that the bridge should be enabled by default. Such behavior is inappropriate for employee desktops; whoever made the call that this kind of sales strategy should be applied to the most security critical of product lines bears the responsibility for the disaster that ensued.

    The only good to come out of it is that, slowly but surely, we're going to win Corporate America's support of industry codes of conduct as a last ditch defense against regulation. Some good, eh guys?

    Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com