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."

flipside

The flip side is that without full disclosure, we're creating an army of script kiddies and crackers whom we cannot track.

Consider the Alternative to Full Disclosure

I worked on the COAST (now CERIAS [purdue.edu]) Vulnerability Database as an academic for about a year. COAST was probably the best known academic security lab in the world and even we had trouble getting good information on vulnerabilities.

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 [cert.org] 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.

Definately not cut & dried...

This issue isn't quite as simple as the author of this article gives it credit for, I don't think. While I do agree that there's a problem here, I don't think the problem is quite what the author suggests.

I am a subscriber to bugtraq (isn't everyone?), and typically, when a vulnerability is found, one of three things happens:

1. Someone posts a working exploit, having not notified the vendor, or having not notified them about the problem at all, or in not enough time to actually fix the problem.
2. Someone posts a working exploit, having notified the vendor 6 months ago, and never having gotten a fix.
3. Someone posts a working exploit well after a vendor has posted a fix to the problem.

Unfortunately, #3 is the rarest of them all. Very seldomly do I see "SUN/RedHat/whoever released a fix for this last month, here's the actual bug.." More often I see "I found this bug" or "I notified them yesterday and haven't gotten a response back yet." Half the exploit-producers seem to be in the game so that they can be, as someone else here mentioned, "first to market" with their clever security exploit.

You'll notice a common element in my list: All of them contain the phrase "working exploit". Many, many of the "I found this bug" postings to bugtraq contain a fully functional script to demonstrate the problem -- A remote root exploit includes a script to (yes, that's right!) give you root on a box, remotely. All a cracker really needs to do is subscribe to bugtraq and wait, and the tools he needs to do his job show up in his lap. Sometimes, these are tools and exploits already found "in the wild," but just as often, they are not.

This, in particular, I have a problem with. In the vast majority of cases, it is possible to explain and demonstrate a security bug without having to ever make an exploit that actually works. One author, recently, posted a "proof of concept" exploit that required, among other things, a good working knowledge of PPC assembly to actually turn into an exploit. He demonstrated the security problem quite well, without giving "script kiddies" a tool they could use to break systems.

Now, granted, there are plenty of people who can take information about a vulnerability, and turn it into working code, and distribute it. These are the real hackers amongst the cracker crowd. But I don't think we need to be making the script kiddies' jobs easier by handing them working exploits on a silver platter.

Then again, these same "real hackers" are perfectly capable of finding these bugs on their own, so hiding an exploit from them (working or non) doesn't really gain you all that much.

I think that, overall, full disclosure is a very important thing -- That's "full disclosure" as in "give everyone the information they need to identify, demonstrate (if feasable), and fix security problems", not full disclosure as in "give away the farm by posting perfectly functional exploit code before you even tell the vendor". Disclosure of their dirty laundry to the world has goaded a number of vendors into fixing long-standing problems with their software. Without forums like Bugtraq, these problems would persist, with only the bad guys knowing anything about them.

The other advantage that full disclosure gives is the ability to discuss and learn from the mistakes of others. For example, there is currently a discussion happening on Bugtraq reguarding user-supplied (or otherwise variable) format strings for *printf-style commands and how they can be abused to give visibility into a (privileged or otherwise) process. Though a true solution may never be reached, I've seen more discussion on the topic in the past few days than I've seen on that topic in the entirety of the rest of my life, and that can't be bad. Discussions of this type pop up from time-to-time on bugtraq, and I'd dare say that anyone who cares to listen to them can find themselves writing more secure code very quickly.

Of course, there's also the downer: Most of the issues I see discussed on bugtraq nowadays are the same types of problems ... that I saw discussed on bugtraq 5 years ago ... Which are the same issues as those brought up by the Morris worm more than 10 years ago. Pity that we'll never learn. *sigh*

Bah..

""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.

He's missing the point.

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".

---------------------------------

Re:Yes, source code for exploits should be release

Well, if there is no manufacturer (Linux, for example) you really have to post your code to the kernel mailing list, which is publicly available. I agree that ready-to-go exploit code isn't very ethical to provide, though. There's a difference between a five-line code snippet that demonstrates the problem, and a nice GUI client that anyone could use to unleash an attack. Of course, some admins would use the nice GUI tool to test their own networks, but there's a limit to how far you can extend that justification.

The mystery here is why people listen to Ranum...

MJR is biased because he is (to my knowledge) the first vendor of a shrink-wrap intrusion detection product to ship/publish a product with a disclosed remote root hole in it. NFR, his network analysis tool, is/was accompanied by a stripped-down web server (ironically, his team wrote this because they thought Apache, the *open source* web server, was insecure!) which had a *stack overflow* in its HTTP GET handler.

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.

Re:Why Script 'Kiddies'?

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...

Give Grey Hats the Right Incentives

I know for a fact that grey hats have been treated foolishly by the corporate establishment types. All they would have to do to get the bug fixes discovered and fixed and patches released before publication is pay the grey hats what they are worth.

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 [dbarter.com] (which won the Hackers Conference prize for "best work in progress" last year [dbarter.com]) was quite young when he discovered his first Netscape exploit Tracker [netscape.com]. 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 [shout.net].

Inspired by such wisdom from corporate establishment wisdom, Dan went on to discover and publish other exploits [shout.net].

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 [geocities.com], way of dealing with any problem.

Either go public or they won't fix it.

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

The myth of many eyes

It's about time somebody stood up to the legions of open source zealots and told them that their cherished view of "many eyes makes bugs shallow" is little more than McCarthy-like jingoism rather than a solid foundation for security.

I'm not saying that obscurity is good for security either mind you, but the fact is that when you have the source code to a product at hand, it becomes a hell of a lot easier to find exploits with a debugger and a bit of patience than it would be with a raw binary. And thanks to the "efforts" of system administrators who would rather spend their time playing Quake than downloading the latest patches and bug-fixes these exploits put thousands of sites that rely on open source software at risk.

The many eyes mantra only applies when many eyes are actually looking at the code. In most cases there are about two people (the programmers) who actually look through the code to fix it, and everyone else is hackers looking for their latest backdoor penetration.

This is an area in which there is so much FUD, from both sides, that a reasoned debate is next to impossible. Until the zealots stop and think, security is going to be something that is argued about rather than realised.

---
Jon E. Erikson

OTOH...

Security through obscurity really only works if a vulnerablilty you have discovered remains hidden from the net in general. Which means that no one else will discover it, a highly unlikely assumption as more and more people probe for such weaknesses. Which senario would *you* want: a vulnerability discovered by some cracker which he shares with his friends to break into sites, or a notice up on SecurityFocus explaining the vulnerability, setting in motion the code writers' ability to close the whole? Personally, I'd rather have more eyes looking at the problem, and trying to fix it.

Why Script 'Kiddies'?

The term script kiddies creates a negative image of young people using Unix/Linux as being only vandals. I'm 15, and I was almost suspended for sshing into my own computer from the school library as they assumed I was breaking security on some system. While some people may classify young people as immature and reckless, I've been using my knowledge of computers for good since I was young. These people should be called what they are, digital grafitti artists with nothing better to do. Security disclosure is necesary for sysadmins to be able to secure their machines, and by eliminating it, only the people on the other side will have the knowledge, as it will eventually leak anyway. But I'm sick of all this childish behavior, I'm getting port scanned a few times a week by random hosts and at least I have inetpaged to let me know about it. I'm just tired of being lumped in with all the 15 year old AOLers with no morals.

Army of script kiddies...

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.
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 /are/ bright and skillfull enough to hide themselves.
Would you rather a giant (but pitifully unskilled) army in front of you, or one very skilled assassin behind you?

he has a point - but it's misinterpreted

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 [l0pht.com]

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!

Let's do that Other Industries comparison again..

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.

Does the car industry bewail him finding that problem with the car? Well.. Correction.. Do the bewail him /openly/, telling him to grow up, get a real job, and stop making trouble.

Now.. Let's take that one step further.. An /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.

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 /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.

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.

Re:Well, of course.

Wow, that was a bad analogy.

The point is more like this -

"How is my house more likely to get broken into?

I have a door with Brand X lock.

1. It's discovered that Brand X locks suck ass. This makes the front page of the paper for some reason. You now have the information to get better locks (if you choose to).

2. It's discovered that Brand X locks suck ass. No one says a word about it, but those doing B&E's soon discover this, and go around caseing all the houses with Brand X locks."

(disregarding for the moment that what kind of lock you have doesn't matter with respect to if your house is going to get broken into or not...)

That's more analogous to the situation here. The 'obscurity' doesn't refer to specific information (passwords, etc - in the lock's case, the specific makeup of your key), but to the information pertaining to the general workings of the security system (i.e. in the lock, how the tumblers work - how easy it would be to pick, etc).

Blah.

Why security through obscurity fails for most

Here's my two cents: Security through obscurity is horrible for the 5-10% of us Linux users that update our machines obsessively in order to get the latest fixes and patches. For the other 90-95% (and virtually all Windows users) it's a failure- the kiddies who want to know about it, go out and find out about it, while that vast number of users sit there deaf and dumb and get hacked. If you want to argue for security through obscurity, you have to justify screwing those who are knowledgeable enough to care (like me.) But if you want to argue security through openness you have to justify screwing the 90% who wouldn't know what a security update was if you hit them in the face with it. Of course, with things like apt and Windows Update, this balance may be changing (numerically speaking) but who can really say for sure?
~luge

Re:He's missing the point.

Script kiddies and hackers are like the Ralph Nader of the auto industry

Hmmm ... Nader was clearly concerned at the lack of safety in contemporary vehicles. This motivated him to write Unsafe At Any Speed to highlight that concern. Script kiddies aren't bothered about the damage they cause, in fact they generally do what they do just for kicks. Don't mistakenly attribute any goodwill to the little fsckers.

Chris

Wishful thinking

Once a problem has been discovered, how do you keep it obscure?

All you can do is go back to the Bad Old Days of closed source cathedral systems and hoping to ghod the vendors get around to fixing their systems some day, because the social structures that surround crackers and kiddiez give you higher status if you are among the first to propagate a new crack. When one of them knows, they all know. It's the same with other group now--crackerz, Tori Amos fans, just whoever. If you have the info, you share it ASAFP and bask in the glory of being the first to break the story.

--

More scripts! Really!

Marcus has the exact wrong idea.

Now that I've said something that everyone will agree with, let me explain why everyone else's comments are also wrong (or at least all of the ones not moderated down under 3).

I'm saying this as a data security consultant, and yes, it's my real job. I need, as soon as possible, to see the exact technical details of every new exploit. If someone has written an attack script, I need that too. Why? Any IDS that's worth the HD space it takes up allows you to write custom rules. If I know exactly what a given attack is going to look like, I can write very efficient rules to report/stop it. If I don't, I may have to guess what this attack looks like, or leave myself unprotected. Full disclosure reporting is the ONLY thing that provides this type of response for me, the guy who's really doing the work.

Re:He's missing the point.

Say what you will about Ralph Nader, but I think he's just a little bit above the equivalent functional level of a script kiddy. Ralph Nader exposed the fallacies of the auto industry, like these "grey hats" -- that is, he actually did the research and fact-finding himself.

The equivalent of a "script kiddy" as applied to the auto industry of days past would be a driver who deliberately caused fatal auto accidents to expl0it the safety problems. Script kiddies don't actually find security problems; they just use crax0rz provided by grey hat sources (or by more knowledgeable black hats) to exploit the weaknesses. No thinking required.

Security Through Threat

The article does not refute the argument that those who empower script kiddies are helping potential victims... it just proves they aren't being very nice about it. We might call the disclosure of vulnerabilities to kiddie-scripts security through threat. The idea, as I understand it, is that these holes will eventually be found out and exploited. No matter how quiet we try to be, eventually someone malicious will find them and exploit them, and if possible script that exploit. The longer this is put off, the more entrenched and widespread that hole will be, and the greater the potential damage.
Okay, but what about the idea that they could be kept quiet for just a little while, while the good guys get it fixed? I think the STT people have decided that things don't work that way. Remember how effective it was when all the programmers quietly went to management and told them that there might be some problems coming up if they didn't start converting to four-digit dates? It took publicity and widespread fear before most businesses started putting serious resources into Y2K conversion, and it's not unreasonable that the same is true of security holes. Tell them that there's a potential problem, and get the runaround while the money goes to more immediately profitable things. But if the populace is whipped up over the prospect of another Melissa, there will be action.

I don't think that these grey-hat types are unaware that they're responsible for a lot of kiddie attacks. But perhaps if the kiddies are a force of nature, unstoppable by law or society, software companies will have no choice but to write good products, with competent security audits and up-to-date patches. That's a goal I can see someone willingly enduring a bunch of 1337 bullshit for.

- Michael Cohn

Some of the things that need to be done...

Full disclosure helps, but in some cases is too extreme, does source code for a particular exploit really need to be published? In reality, when an exploit surfaces, it should be publicised, but not in detail. This would give reputable companies time to fix it (presuming the finder gave details to the company and perhaps a handful of reputable security experts who might be able to create a workaround plus IDS fingerprints).

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.

Re:Bah..

90% of the (exploitable) bugs in Windows are in the networking code and the scripting code. It doesn't matter if there's a bug in an installer because a malicious attacker can't run the installer without having already gained control of the machine.

Sure, Windows will *never* be bug free, and it's silly to expect that it will. Especially when you consider all the things that people think of as parts of windows, from the essential like ScanDisk and the Networking to the mundane like Solitaire...

But, if the OS is well designed, a program like Solitaire could never take out the whole OS when it crashed, so it could be dealt with seperately. Only the core system would need to be rock stable, the rest could be restarted easily. (Beos's networking dies on me every now and then (I'm breaking the rules using two identical network cards) which is annoying, but I can restart it with the click of a button, unlike in MS where I have to reboot.)

Once the system is stable and can't be crashed by a badly written solitaire game, you go on to bug-fix the important parts, the external programs, those that deal with the outside world.

Your HTML renderer, your network stack, your scripting, those need to be locked down.

A smart designer can tell what parts of the system need to be secure and which don't. If the attacker could only get to one bug by already having exploited a larger bug (crash solitaire by using a buffer overflow in networking to execute arbitrary local commands) then the one bug is fairly minor.

Microsoft could secure Windows, at least as much so as BeOS or any other non-multiuser OS, with a little work but they refuse, because it's easier to only fix what has to be fixed.

I agree with the person who said that bugs in products from companies like Microsoft who don't fix the bugs until they make the news, should be made public without warning them... That way they take the biggest credibility hit.

If it Truly Is Obscure, it may work...

The usual assumption is, in the area of cryptography, that using an obscure cipher probably means that it will be fundamentally weak, and that it is preferable to "flow with the herd" and use Blowfish, Triple DES, or whatever flows out of the AES effort.

Another view is taken by Terry Ritter, of Ciphers By Ritter. [io.com]

His article Cryptography: Is Staying with the Herd Really Best? [io.com] 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:

• Create "heavily armoured elephants," with comprehensive, well-understood sets of defenses.

  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.

• The other approach might be described as a "herd of gazelles."

  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.

Ranum sounds cornered, but he's not right

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.