Slashdot Mirror
Security Through Obscurity A GOOD Thing?
twrayinma writes: "In this story Marcus Ranum, CTO for Network Flight Recorder, claims that "Full disclosure is creating armies and armies of script kiddies" and that "grey hat" hackers aren't really interested in better security."
Frankly, partial or non-disclosure keeps the information from the people who really need it. Academics need the information to keep up with and understand what a vulnerability really is. Things like CERT advisories are useless for this. They don't have the information needed to figure out what the vulnerability really is and how to classify it. Another group hurt by partial or non-disclosure is sysadmins. If a sysadmin scans bugtraq even weekly, he can often have a patch or workaround for a vulnerability in his systems long before the vendor releases anything. Open source really rules here where there are usually alternatives such as fixing the code or getting a different free package put up instead.
Even if there exists some cabal of fully informed individuals, they are always going to leave out many of the folks that need the info. Face it, most vulnerability information is useless without enough info to exploit it.
""A lot of the vulnerabilities that are being disclosed are researched for the sole purpose of disclosing them," he said. "Someone who releases a harmful program through a press release has a different agenda than to help you."
And then you have companies like Microsoft, who when notified of an exploit by say, USSR Labs, on June 11th, don't get a fix out, and instead wait until it goes public, and then say "we'll have a fix out this afternoon!"
The only way to get some things fixed is kick companies in the ass, and making holes public is a great way of doing it.
BilldaCat
It's the very army of script kiddies and hackers out there that are FORCING major corporations to tighten up their code. Script kiddies and hackers are like the Ralph Nader of the auto industry (remember his book, "Unsafe at Any Speed"). The analogy is the same. Nader pointed out that the auto industry was producing unsafe cars. Hackers are pointing out that software companies are producing software that leave your corporate and home networks vunerable to attack. Except that rather than publishing a book like Nader did, they're publishing the weaknesses and potential methods of attacks.
Nader had to wait years for Congress to pass laws forcing the auto industry to tighten up. I think hackers are a bit more effective. They're forcing companies to tighten up at "Internet speed".
---------------------------------
"We're sorry, but the website you're trying to reach has been disconnected."
No wonder he's not fond of "gray hat arms dealers".
Of course, nothing he is saying is backed up by any real researchers. In cryptography, cryptanalysis is a foundation upon which theory is built. Analyzing and breaking algorithms is the respected, hard task. People like Bruce Schneier repeatedly publish papers disclosing flaws not only in cryptographic algorithms, but in protocols that use them!
MJR's nonsensical position is even more amusing based on the people he consorts with and praises. NFR went through much effort to publically associate themselves with the L0pht --- probably the most well-known active source of full-disclosure security information. He also sticks up for people like Dan Farmer and Weitse Venema, both of whom have published information and tools about new security flaws.
The message here is not that "full disclosure is evil". What Marcus longs for are the olden days of private security mailing lists, where only his friends got information about security flaws. Those were also the days in which literally every piece of software was riddled with stack overflows and the most common way of breaking into remote computers was by mounting public NFS shares.
I understand why MJR doesn't like people outside of his insular little clique publishing and discussing security information. But it would be silly to pretend that anything he says is motivated by a desire to secure the Internet.
Yes, it is unfair that many adolescents (probably the majority) get tarnished with this image, but you have to understand where it comes from. While the majority of young people are not crackers, or vandals, the majority of vandals, digital and physical, are under twenty-two. It is the nature of humans and maturity. These young punks (and they are almost always young) screw it up for the rest of us. And a very big part of "the rest of us" is young kids like you, who are, like the rest of us, mature and responsible.
If you really want to know where "script-kiddy" comes from, just look this line from your own post: "But I'm sick of all this childish behavior...". That's exactly it. We call them "kiddies" because their behavior is childish. Immaturity below their years.
You, being responsible, are not a kid. You are a young adult. And yeah, it sucks that the you're treated like crap by know-nothing adults because of idiots in your age-group. But unfortunately, what we call those idiots isn't going to change that. The only thing that will change that will be to educate those know-nothings that are unfortunately in charge of the stuff they know nothing about in too many places.
Now if only I knew how to do that...
The cake is a pie
In otherwords, be businessmen.
It appears the corporate establishment types are so concerned about real money going into the hands of young guys with an attitude that they would rather subject the Internet community to unnecessary risks, and their stockholders to violations of their fiduciary trust than pay the grey hats what they are worth.
For example, Dan Brumleve, the developer of DBarter (which won the Hackers Conference prize for "best work in progress" last year) was quite young when he discovered his first Netscape exploit Tracker. Netscape subsequently gave credit for finding the "Tracker" hole to a guy from Bell Labs. Their excuse for doing this was that they already knew about the Tracker exploit, having been told of it by Bell Labs -- an act that might have been rational if the Bell Labs exploit had been the one posted to Dan's web site. The problem was, Dan's exploit still functioned under the Netscape's fix to the Bell Labs exploit.
Dan has documented the behavior of corporate establishment types in this fiasco.
Inspired by such wisdom from corporate establishment wisdom, Dan went on to discover and publish other exploits.
At no time was Dan offered more money by Netscape than he was making as an independent contractor hacking Perl scripts for e-commerce web sites, although Dan did ask for such compensation.
Each time Dan published one of his exploits, Netscape stock went down 5%, and some of Dans friends made some money shorting Netscape on advanced knowledge of these exploits before Netscape was finally bought out by AOL.
OK, Dan's exploits may not have caused the Netscape stock price drops (though, try telling that to the guys who made money assuming they did). But even so, this attitude toward grey hats, that controlling them by legislating against them, is going to drive them underground. Society has "punkified" a lot of these young men already so threatening them with prisoner gang rape isn't going to twist their heads around that much -- aside from being a morally reprehensible, not to mention unconstitutional, way of dealing with any problem.
Seastead this.
I found my first new exploits in 1994, when I had the opportunity to research AIX 3.2.5 as part of a tiger team. We found a list of about 10 ways to get root on the system (actually more, but this were the ten worst) in only a single way of systematic research of a stock configuration directly from the current installation tape. We called the vendor and waited. Nothing happened. For months.
I had to write an article in a (german) computer magazine under pseudonym, then take that article to the local vendors office and say "Look, now it is even in the papers" in order to get a reaction from then. IBM didn't care a shit about security back then, unless they were forced to by publicity.
This has thorougly changed now, but only due to full disclosure.
And even now you need disclosure and publicity to get people to get their act together. A large german online bookshop had their server wide open for nine months after I informed them that I was able to connect to their Oracle on their webserver using my Oracle installation, and get all their credit card data. Only after they ended up on in the same german computer magazine they decided to firewall themselves shut.
With open source the situation is better, but only slightly. I was able to break out of safe_mode in PHP 3.0.13 and below using a bug in their popen() implementation, and fixed it in CVS. I then posted the bug on bugtraq, forcing the PHP team to release 3.0.14 with the fix immediately. Nice reaction, but the core team didn't like me publicizing on bugtraq.
When I found a similar bug to break out of safe_mode using the mail() function, I did not create a fix, and did not post on bugtraq, but informed them privately of my findings. The fix went into CVS in under 3 weeks, but 3.0.15 was released only three weeks later.
I find this disappointing: Even in Open Source you get appropriate reaction to security issues only by forcing updates through full disclosure. Well, I for my part have learned my lesson: I find a security related bug, it goes to bugtraq - no delay, no mercy. The waiting ain't worth it.
© Copyright 2000 Kristian Köhntopp
Shine on, you crazy diamond.
While scipt kiddies are bad, and lots of them are very bad, they are reletivly easy to discover, and are (usually) not bright or skillfull enough to cover their tracks. Publishing holes probably does make more of them, but they force you to patch these holes. /are/ bright and skillfull enough to hide themselves.
If the holes weren't published, you wouldn't be alerted to them, and then the only people who knew about them would be people who
Would you rather a giant (but pitifully unskilled) army in front of you, or one very skilled assassin behind you?
Calmacil
I can't seem to face up to the facts, I'm tense and nervous and I can't relax... --Talking Heads
Sometimes I feel that certain people in security view the products and the admins using those products as the enemy, and not the crackers at all!
Who was cracking Novell's LANManager password scheme - included in Win9x - before l0phtcrack was released? How many DDoS attacks had you heard of before the release of trinoo, etc? What about fragmented IP packets before teardrop?
The real problem with full disclosure is not that holes aren't patched - publicly announced bugs usually do get fixed sooner rather than later. The problem is that users don't always deploy the patches. In the meanwhile, well-meaning (or otherwise) "grey hats" who have coded exploits to holes they discovered - usually in order to enhance their media shebang and sell more of their own security "solutions" - have handed a tool to skript kidz who simply hunt the net until they find a box whose harassed admin hasn't installed the latest patch. Alone, many of these "crackers" couldn't crack a paper bag. With the utilities in their arsenal, it's trivial.
See this related article written by the l0pht:
http://www.l0pht.com/~oblivion/so apbox/index.html
I'm all for disclosure of security holes - it keeps vendors honest, and it allows for creative security community solutions. It may not be in the best interests of the world (and info security does have a global impact these days) to code actual *demos* in order to pressure vendors into implementing fixes. Just explain the hole, explain the danger, heck even explain a step-by-step exploit. Just dont code the bitch. Your neighborhood harassed admin will thank you.
-konstant
Yes! We are all individuals! I'm not!
-konstant
Yes! We are all individuals! I'm not!
An individual discovers that, if he jacks the steering hard and to the left, the power steering fails, and endangers the vehicle, and everyone around him.
/openly/, telling him to grow up, get a real job, and stop making trouble.
/extremely/ expensive car is claimed by the manufacturer to be unstealable, because it has fashioned impenetrable door locks. Our enterprising car aficionado notices that, if he wiggles a dummy key just right, the 'impenetrable' lock opens, after which he can do whatever he wants with the car.
/moment/ you discover a new vunerability, scream your head off about it, and try to protect the soft spot until you can get a fix.
Does the car industry bewail him finding that problem with the car? Well.. Correction.. Do the bewail him
Now.. Let's take that one step further.. An
Does the automotive industry scream? Yes, for a little bit.. But they issue a retrofit pretty damn quick. Would they scream if he hadn't told everyone about it? Would they hurry with the refit? Would people trust them, in the future, by default?
In the I/T world, the best approach, with so many faulty packages, is a belt-and-suspenders approach. Layer several 'impenetrable' and 'infallible' packages in such a way that possible weaknesses should be isolated and shielded, then apply careful monitoring. And the
For all these companies, complaining about how a grey hat's article on such-and-such bug ruins the safety of their entire site, I have ZERO pity, because they have obviously made the mistake of placing all their eggs in one basket.
Weapons of Mass Analysis
Egress filtering. Yep, it's argued earlier in the iTrace story...but it is a good idea. Perhaps a mandatory requirement that no ISP passes traffic that isn't in there IP allocation. (there is *no* good reason for routing somebody else's IPs, right?). Yeah, there might be an issue with speed of filtering, but it really is the only way to prevent havoc. (oh, and iTrace is a step in the right direction too...at least a temporary one)
Malicious activity should be viewed as just that. DoS'ing, cracking, exploiting, rooting, sniffing should all be classified as illegal, and penalties must be established. Although the cost of tracking down perpetrators is high, the increasing number of these l337 scr1p7 k1dd13s is only going to cause more and more financial loss, especially as the Internet becomes more ingrained in society. Cracking system (even if there is no financial loss) should still be viewed as the intrusive crime that it is, and should be prosecuted. (of course, that's very difficult across borders, but something *must* be done...)
Relying on obscurity to provide any level of security is a bad idea. There are talented people who can find flaws in any closed system, given enough time and effort. But this is no excuse to start handing out information that doesn't need to become public. A source code example isn't required to demonstrate a flaw to the public, so it doesn't need to be distributed.
Another view is taken by Terry Ritter, of Ciphers By Ritter.
His article Cryptography: Is Staying with the Herd Really Best? questions that; his view is that there should be a framework for there to be a rich set of ciphers in use, and that systems should readily, and dynamically, be able to shift to new ones should an older one be broken.
There are, widely stroking with the brush, two major approaches to security:
It is fairly well guaranteed that the armour will prove challenging to would-be attackers, whether we're talking about a crypto system, or a B1-certified version of Unix.
Unfortunately, since such systems are big, heavy, and complex to assemble, if they do have weaknesses, they will prove extremely vulnerable to attack at that weak point.
Gazelles are not heavily armoured; they depend on moving quickly to avoid capture by those that would eat them.
More importantly, they are "physically independent." If a lion is busy chasing one gazelle, he can't catch any of the others.
The history of major Internet security breaches demonstrates that putting all the eggs in one "pot" is dangerous:
- The Morris "worm" only affected systems running Ultrix and SunOS
- The Melissa "virus" affected only those running Microsoft apps
- Ditto for ILOVEYOU
If people are running different systems, they will have different vulnerabilities, and so long as the systems do not broadcast the evidences of vulnerabilities, there is value in obscuring the vulnerabilities.If you're not part of the solution, you're part of the precipitate.
Marcus Ranum is great, and he's a great speaker, but he's wrong. It is true that the mass distribution of hacking tools has created a mass of script kiddies. This is an offset of a lot of kids, possibly alienated and marginalized, with excellent basic computer skills and too much time, and not enough legitimate purpose. They do it as a method for asserting themselves. A lot of hacks are a bit like "tagging". You can't drive up 101 in silicon valley without seeing tags all over the overpasses.
Full disclosure allows people responsible for security to verify vulnerabilities, patch holes, etc. The no-disclosure alternative leads to an unknown mass of hackers, out there trading amongst themselves. It will not stop distribution, even to kiddies, who will spend endless hours on #supah_hot_shells on irc pining away for a new tool. Meanwhile, with no public disclosure, who will protect us?
You guessed it, Network Flight Recorder. It, and a cadre of other companies like it, will share their secrets with each other under the blanket of draconian NDAs.
Part of the problem is just that we've recently had a lot of distributed dos attack "exploits". The problem being, you can prevent yourself from being part of it, but you can't prevent yourself from being a victim of it. There's nothing worse that running a tight ship, tuning your box(es) to be safe, and then eating 200megs of smurf because some user with a shell on your machine kicked some flooding fool off #stay_away_flooders.
Still, the smurf problem (and those like it) are not insurmountable, and people are now aware the problem must be dealt with in an automated way, and they're working on it. Meanwhile, law enforcement will grow more adept at tracking this sort of thing. As many people have pointed out, few connections to the net are truly anonymous. Meanwhile, cooperative logging will grow more likely. Logs will stream offsite immediately to a super-safe host, so even if you break into a system, your tracks are set in stone, etc. Meanwhile, those of us who just want safe boxes can keep them safe.
Yeah, well, I'm no zealot, but I can clearly see the problem isn't the release of source code, but the lazy sysadmins. Closing the source as a method of solving the problem of lazy admins is not a solution at all. It will give you a slightly greater amount of time before the exploits are found, but then there won't be a bugtraq post about the exploit, and the boxes will still be cracked. You've only delayed your doom, at the cost of making it worse when it inevitably comes.
The 'many eyes' mantra isn't a mantra... it's sound reasoning that has been demonstrated to be effective. Yes, it does actually require many eyes, and more importantly for people to pay attention when the mouths associated with those eyes speak up about a problem -- which is the point. Get rid of the lazy sysadmins, and the article wouldn't have been written.
What I can only hope is that the spat of low-effort cracking and script kiddies will serve as a wake-up call to those people who think these problems will just fix themselves. To an extent, it seems to have, but I hope they don't react by trying to close the source to protect their own laziness.
To a limited extent it has worked -- I'm paying more attention to security now myself. and I'm definately a lazy admin (but I don't make any money off my administration efforts, and it's just my box ^_^)
The enemies of Democracy are
While i prefer a system of posting security holes in the open to the alternatives (namely that the security holes are spread in obscure cracker forums and thus will have a far longer lifetime) i find it debatable to provide readily usable scripts for even the dumbest to use freely. In most cases a simple "at this point a vulnerability exists which can be used for such and such a form of attack by people with such and such privileges" should give the maker of the software enough hints to fix the hole while it would take at least a little work for a cracker to make use of that information thus greatly reducing the number of potential crackers.
The only argument for giving away such scripts is to exert pressure on a company that totally ignores announcements of bugs otherwise and will only react when critical comments start to effect their product sales. I think the fairest way would be to give the company some headstart to fix the hole so they can provide the fix with the report (which should honor the finder of the bug for his efforts) and proceed to publish the hole on some open forum after a few days. If the company chooses to ignore the bug it will only make them look worse later. There is no need to add a script to the exploit as these will sprout up anyway as soon as the hole is known.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
Posted by BSD-Pat:
:p). And all it takes is sometimes *time* looking at a problem to fix it. Sometimes I *know* theres an issue, and I don;t want to invite trouble (like in the case of several DoS attacks we've had).
Security itself is mostly common sense, you need to know whencertain actions are good.
Now we published our security setup on slashdot, mostly because its nothing special in and of itself. However I don;t publish our *policy* and implementation.
Why? its just never a good idea, its common sense.
I hate the words "Security through Obscurity", mostly because, sometimes its "Security Through Prudence".
There are certain times I should never disclose actual implemenattion of a security plan. It would, in essence make it easier for those who are not even "grey hats" (not that I don't trust you slashdotters
Network Engineers, Software Engineers, Security Engineers, they are nothing if but human. Now if you privately notify them about a hole and they refuse to do anything about it, or even acknowledge it, thats a *different* story.
the other thing thats important in this is peer review. A team of people should be in on implementation, its the same way with code. There should always be someone reviewing your work, or else you could FUBAR everything.
So lets forget security through obscurity, if being obscure is your only protection, then you are stupid. If prudence is the reason, simply until you can fix something known by you, then, maybe thats a good idea.
-Pat