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."
"...NAI programmers created a custom server that..."
It is actually the firewall guys that screwed up, not the censorware. So censorware is just a bad idea for the other 101 reasons, not security.
On a side note, does anyone actually read the stories before they are posted?
Somebody please mdoerate this piece of drive down
as overrated?
This is a major firewall product. This major firewall product comes with trial software that creates a hole in the one feature which is the only reason to buy the product. It is a major gaffe and is newsworthy. The fact that it involves Censorware is merely additional irony.
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Anomalous: deviating from what is usual, normal, or expected
Canard: a false or unfounded repor
That's a good idea. Another good idea is to do a simple ``netstat'' dump of listening sockets on the firewall. I hope that any firewall admin is already doing this--it is an important check that things are as you intended them to be. Any program which cannot bind to specific interfaces has no business on a firewall. It certainly shouldn't call itself a ``proxy''.
I know the first time I ran ``netstat -l'' on a RedHat 6.1 system I was quite surprised by the cruft hanging around. Before that machine took on its firewall/masq duties, all those unwanted daemons were removed.
It was called Sonicwall, and as far as I could tell, it was working fine as a firewall.
But as a censorware package, it had a lot to be desired. I wanted to visit my own web site, http://www.amazing.com . "This site has been blocked by SonicWall". Fine, maybe my site has wierd stuff on it someplace, it has so many pages, how can I even tell nowadays? So I added my site to the "let through anyway" list and went on.
Then I tried visiting http://www.freshmeat.net/ to get some software for my Linux box.
"This site has been blocked by SonicWall"
In a moment of pure anger, I shut off filtering and rebooted the SonicWall. End of problem.
D
----
I blame them both. IMO, nothing exposed to tainted data should be running as root. Particularly on a firewall!
Unsure this is tair. We're talking about an app that needs to do a raw interface sniff through something like BPF, and then make decisions based on that sniff regarding whether or not to *actively* forward the individual packets through frames on the internal interface. This app is using entirely tainted data--everything it receives is untrusted content. Root or not, any compromise of the firewall code would be required to grant the capability to forward arbitrary packets to the internal network, which directly contravenes the stated purpose of the firewall itself.
In short, the coders can't be blamed on a permissions level--it's conceptually impossible for the most of the serious damage to have been prevented "if only the app wasn't root". About the best I can imagine is if the execution context of the firewall didn't share read/write access to the storage medium of the firewall code. That prevents long lasting trojans, at the expense of reducing the number of sites that will upgrade their firewalls.
Yours Truly,
Dan Kaminsky
DoxPara Research
http://www.doxpara.com
irony n 1: witty language used to convey insults or scorn; "he used sarcasm to upset his opponent"; "irony is wasted on the stupid" [syn: sarcasm, satire, caustic remark] 2: incongruity between what might be expected and what actually occurs: "the irony of Ireland's copying the nation she most hated" 3: a trope that involves incongruity between what is expected and what occurs Source: WordNet ® 1.6, © 1997 Princeton University
I think my usage falls neatly under # 2 and #3. Damn, do you all have to make me keep reliving my failures in English class???? 8^}
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
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!)
The Smartfilter web filter list is over 5 meg, with close to a million entries, and it's updated weekly. Which open source individuals are going to maintain that list?
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
Hmm...
Mozilla x (Perl + Python) = New IDE
Firewall + Censorware = Trouble
It seems the million dollars for solving mathematical puzzles is preying on the minds of the Slashdot folks....
dylan_-
--
Igor Presnyakov stole my hat
I work at a *big* corporation, and although it hasn't happened for a while, there was a period when our proxy would get confused, and respond to perfectly innocent http requests, with cached porn JPEGs.
... quite "extreme", some of them, too. I wonder which URL gets logged -- they one you asked for, or the one it delivers.... scary.
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.
Hashing the CyberNot list is not the issue. It is designed for speed, not security. If the list access was slow, it would make the product useless, if you had to wait an addition .5 seconds on every lookup. Hashing the list was probably meant as a prevent someone from taking the list and selling their own product (a filter, or a list of XXX sites). Using the same hash for the password was just plain lazy/sloppy!
Fight Spammers!
Back when I worked for Norman Data Defense on their firewall product (which failed, so don't wonder if you never heard of it) they wanted to add in CyberPatrol. I screamed and yelled at management that this was an incredibly stupid thing to do, that it would be a huge gaping security hole to run sofware that we couldn't control on the firewall box.
(Disclosure: I used to work at TIS (though not on Gauntlet) and own Network Associates stock.)
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
This is true if you are informed by your own people that your product has a flaw. If you are informed by a client, hang your head in shame. The whole point of a firewall is security that should be tested and retested and broken and fixed before it is released.
What a black eye for NAI's reputation ...
Please, let's be clear on this: There *are* Firewall/Censorware pacakges that don't automatically create security holes in your network.
Some are even good censorware, like using junkbuster in conjunction with a firewall to reject evil cookies and filter unwanted ads, and repel crackers.
It's amazing how much faster it is to surf without waiting for some silly ads to finish downloading, so you can see the rest of the page.
(Just my $0.02)
--
--
Look, I know the road is rough, and the work is hard; But we'll burn every bridge as we get to it, OK?
Just how secure the "World's second most Secure Firewall" is. heh.
Geeky modern art T-shirts
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.
- In my experience and opinion, technical support has definitely taken a turn for the worse. It has become so worthless, IME, that the company I work for doesn't plan to necessarily renew our support contract for the product.
- To me it seems NAI is more interested in adding "bells and whistles", such as "friendly" GUIs, add-ons like CyberPatrol, and improved performance and features under the Ms-WinNT version than it does improving and supporting the reliable, trusted Unix versions. (Indeed: they just announced End-Of-Life for the turn-key BSDI version.)
In other words: it looks to me like NAI is slowly turning Gauntlet into just another "me too", mass-market, point-and-click, Ms-Windoze-Pee-Cee-toy product. Which is really a cryin' shame! Gauntlet always took hits for being more resource-intensive and slower than competing products (it is a proxy firewall), but at least in the past you could always count on two things: you could trust it (I still do--but I wonder for how much longer?) and you could depend on competent tech support in a timely fashion. In short: Gauntlet was a firewall for power-Admins that had a clue! (Hell, they used to ship the thing with source! Patches actually patched the source, re-compiled and installedJust one (increasingly unhappy) Admin's opinion. Speaking for myself and not the company for which I work.
Unfortunately, we now have another reason to show why your firewall (or any other security device, IMHO)should be the only software running on a particular machine, other than the OS.
:)
Unfortunately, in these days of consolidation and price sharing, nobody seems to be listening. I don't know how many requests I get a week from different people asking for different software to be installed on the firewalls ("Can we make the firewall a DNS server? SMTP server? NTP server?")
This also highlights another thing we in the security industry should be worried about: Bugs in code. With packages such as checkpoint becoming larger and larger, it is getting harder to keep track of the internals of exactly what is happening inside these security products. While it probably isn't feasible, it would be nice to have some sort of outside auditing done on the code, as a sanity check. Heck, open source it.
Also, this may make people take a closer look at firewall appliances such as the nokia. Having something that is pretty much a dedicated firewall solution (aka, stripped down OS, running nothing else but firewall) becomes more attractive.
So, the recipe for a good firewall is:
1) Install OS
2) De-install everything not needed to let the box run.
3) Harden OS (also, take a look at known security bugs for the OS you are running, it may save you grief in the long run).
4) Install firewall code. If you don't need some portion of the firewall, don't install/activate it! Also, RTFM. The release notes and web pages of the companies involved can save you trouble in the long run.
Of course, you need a little more than this to develop true 'network security', but this will at least help you get the firewall portion right.....
--Doc
A separate problem is the complexity of the programming interface. I haven't seen it, but the descriptions in the articles sound like NAI had to do a lot of work to interface to it, enough that they did so unsuccessfully. But censorware's designed to be used in firewalls, so the interfaces need to be clean and well-documented, because you can't afford security mistakes here. There should be two or three parts to the interface - one that takes a URL and returns approve/reject, and one that provides administrative control over preferences, which is obviously more complex but should still be easy to do cleanly. The potential third part is processing the returned http itself (looking for dirty words or whatever), which is also hard, and needs to be cleanly designed so you can use it safely.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
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
You can set squid up to block sites all different ways using ACLs. There's at least one place to get lists of porn sites in squid's ACL list format (I believe it's in the FAQ), so you can easily accomplish this job with free software. It's also easy to set up your firewall to transparently send all web traffic through squid. Why bother with the commercial packages at all?
Or firewall product shipped with a copy of CyberPatrol censorware which I did not install. Instead, I (every now and then) simply email everyone a copy of the proxy access logs. I don't read them, I have better and more interesting things to do than be a corporate censor. Must be working though, seems there is a great interest by the users in determining what the IP address of thier station is >:-)
Scanning is one option, but there are companies out there who rely on that firewall to keep all the bad guys out. (i.e. no backup plan) If you can get root access, you can essentially destroy any protection that the firewall was once providing and potentially run rampant depending on what is exposed internally. (promiscuous r* commands, XWindows and packet sniffers come to mind for starters...)
-- A computer without COBOL and Fortran is like a piece of chocolate cake without ketchup and mustard
Thad
The Bolachek Journals
My take is that this story highlights the technical oversights that CyberPatrol is making.
/. submission. It is more like a headline of "Technically incompetent bomb maker blows off own foot" or "Neighborhood bully gets butt kicked, lunch money stolen", irony is quite humors as long as it wasn't your firewall. I would be quite pissed if it was my firewall they pooched.
I have strong concerns about the methods they employ to select what content and sites to filter and this points to severe technical problems with their implementation. I think you read the wrong message into its
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
Every time someone integrates complex functionality you have the opportunity for errors.
The more complex the system more more likely it is to have problems. Same issue for cars (eg a Formula 1 car less reliable than a Ford Focus, but it has a different job to do so..).
Like I always say KISS - Keep It Simple Stupid (Ok so the Army uses this as well).
The simpler the system more reliable it _tends_ to be.
When security is involved, I like simple because I'm stupid.