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."
2a. The company sues you under the DMCA after you foolishly admit to them that you bypassed their access control.
___
__
Do ya feel happy-go-lucky, punk?
This is FUD, pure and simple. There's nothing gray about CERT (they provide a legitimate and valuable service). And there's nothing gray about rootkits or the people who write them (there's no legitimite purpose rootkits can be put to)
-y
150 Opening BINARY mode data connection for slashdot.sig (129323052 bytes).
Within a very short period of time, someone other than the people who discovered and publicised the hole will create the skr1p7 |<1dd13 t00lz and the havoc will begin again.
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
I find this story vaguely hypocritical considering Slashdot obscured their source code for about 3 years to maintain security.
Wouldn't you find it more hypocritical if Slashdot, the NEWS site, decided not to post this story that they knew their readers would be interested in BECAUSE they obscured their source to maintain security, and people would call them hypocrites?
When the author speaks of "script kiddies", he implies an attacker who does not fundamentally understand the technology they are exploiting.
It seems like the issue he _should_ have been focusing on is the problem of a clever minority creating easy-to-use pre-packaged cracking tools, thus empowering masses of dumb angry kids who would otherwise be completely harmless.
Clearly one motivation for widely distributing a cracking tool that any idiot could use would be to force an unresponsive & incompetent software company to fix obvious dangerous problems that they might otherwise continue to ignore. This could be seen as legitimate activism.
While a penetration tool that is easy to use facilitates legitimate security auditing, it seems reasonable to question the judgement of lowering the threshold of competence required to wage an effective attack...
Just because a security bug does not goes to a newspaper does not mean that the script kids don't get their hand in the exploit. Bugs should be common knowledge just because people should have the right to know when they are in danger.
Not publicy a security bug is like shiping explosives in a train with no marks on the box warning what they are. With the marks the people doing the transportation could take a serie of precautions to avoid the disaster, if they realy care about their lives. The same is true for software.
Shure there is 90% or more of computer users that couldn't care less about security, and that is not their fault. Microsoft make money in hiding problems under the carpet, and making hard thing looks, and I repeat LOOK, easy. Managing a computer system so it would be safe is not easy, not in UNIX and not in windows, in windows it looks like an easy task, but it isn't.
Well the bottom line is hiding problems will get people with a FALSE sense of security.
PEOPLE MUST KNOW WHEN THEY ARE IN DANGER.
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabitt hole goes"
[]'s Victor Bogado da Silva Lins
^[:wq
I think that your analogy using Ralph Nader is skewed.
<BR><BR>
Nader used the data in his book to push congress to pass automotive safety standard laws that would eventually lead up to laws like the airbag and seatbelt laws...this sort of ruin-it-for-the-rest-of-us legislature means that a company is less likely to market safety in their cars as people tend to trust the government standard of safety (which is marginal, cars aren't safe, period). This also removes power of choice from the consumer. (ie I should be able to choose weather or not I want to pay for a premium safety item in a car, like airbags, anti-lock brakes, rain/snow tires, etc)
<BR><BR>
This is simply not the capitalist way (and we <I>do</I> live in a capitalist country). Once a hacker publicizes a vulernability, a developer has a choice as to weather or not they want to fix the hole.
<BR><BR>
If we used your Nader analogy, said hacker would find an exploit, write a book about it, testify before congress, and get a law pased FORCING major corporations to tighten up their code.
<BR><BR>
Anyone here want legislature concerning code maintainence?
<BR><BR><BR>
I know that this is a stretch, but this is what Nader did...and the parallel I draw isn't <I>that</I> far fetched. The last thing we need is more people who help create laws which (in one way or another) degrade our civil liberties.
<BR><BR>
not like I have an opinion or anything
-Turkey
- Source code allows me to compile an executable to test if my current systems are vulnerable. "Just patch," you say. The problems with this are twofold:
- Many of the patches that are released are not fulled regression tested on some of the more obscure problems. A choice between "Well, I could install this non-regression tested patch on an important machine" or "I can't figure out if I'm even vulnerable to this one!" is not much of a choice at all.
- Not all of these exploits can be solved wtih a simple patch, some require reconfiguration, new software, whatever.
- Source code, rather than an executable, allows me to make sure I am not installing a Trojan, e.g. "New vulnerability found! Use this binary to test your system!" and having it format c: or alter my
/bin/login - Source code allows me to further incorporate detection of this vulnerability into an automated scanner, for later work. As I add machines, I run an automated scan against them.
I simply cannot count on vendors to getting around to fixing things. I will give a practical, if Microsoft, example, namely the RFPoison DoS attack on the IPC$ for services.exe under WinNT 4.0. I was nailed by this one almost two years ago, quite casually (mind you, by someone who was not a mere script kiddie). When did Microsoft correct this? Service Pack 6. Of course, if you search on their site, they also claim it to be a not-fully-tested post Service Pack 6a hotfix on a different page. Which is it? Apparently, not even they know.It was a security issue (DoS). It was obscure (MS sure as hell didn't tell me). I got nailed. Security through obscurity failed in this particular instance. It would be interesting to do a comparison of various exploits to see how they work out, rather than us all shouting opinions, ambiguous logic, and, in my case, lousy anecdotal evidence.
Then some 5kr1p7 k1dd13 stumbles on an exploit and suddenly the bulk of the world's computer users is vulnerable.
I think you're rather overestimating the typical level of skill and competence possessed by the average script kiddie.
Most anecdotal evidence (and certainly my server logs) point to the fact that most attacks consist of running whatever tools they have over whatever hosts they 'like the look of'. If nothing cracks, they move on.
I don't honestly think that, if the tools were to dry up, these same kiddies would actually bother to learn about the theory and practice of security. I'd bet that most of them don't even understand how TCP/IP works, or know how to program beyond a trivial level in C.
Cheers, Nick.
-- O improbe amor, quid non mortalia pectora cogis!
How do you know how many people are actually looking at the source code? I've been using Linux (on and off) since 1994. I'm a professional software engineer. The only time that I've even bothered looking at any open source code was when the readme file instructed me to change something so that it would build for my machine. I don't have time or the urge to look through the code for most things. Most of my friends or co-workers who have the ability to find these problems seem even less motivated to look at source code to the software they use than me!
Just looking at the code isn't good enough either: you have to understand it before you can start seeing security problems. Only a very small percentage of users of most pieces of software are going to bother examining the code in depth. Imagine how many users of a product there would be if you had 1 million people (2 million eyes) actually looking at the source and understanding it sufficiently to spot problems.
> The Morris "worm" only affected systems running
> Ultrix and SunOS
Where did you get this piece of information? The
morris worm predates both of those operating
systems, to the best of my knowledge. Its primary
target was VAXen running BSD (which was the only
os/architecture pair the finger bo existed on, which was its primary means of replication.
Just to be fair, the l0pht article is really a different point of view. Their argument is not that you shouldn't announce a vulnerablitity (or even code an example), but that if you do, you should announce the solution at the same time.
They are commenting on security venders that announce a problem, then want you to buy their product for the fix.
# (/.);;
- : float -> float -> float =
How about a middle ground here? Someone's got to be told about major security holes, so that they can be fixed. Sure. But do we need pre-packaged exploit code to be avaliable?
For example: the Outlook date header vulnerability. Why not just say "there's a buffer overflow problem with OE" That seems plenty for people fix it. Instead, they put out example code. That's just ASKING for it. They should have had comments
/* You don't need to understand this stuff */
...
/* Your trojan goes here */
main(void)
{
return;
}
Nader didn't do it by running cars off the road and hurting people.
I also doubt your socially conscious kiddies do many public education activities or letter writing campaigns before causing damage.
I recommend this book "Java Design Patterns. A Tutorial" by James W. Cooper. This book describes in a great detail design patterns in Java and their use, it also has UML diagrams for all of them. Those of us who are familiar with 'Gang of Four' and their "Design Patterns" book would find this really usefull. Enjoy!
http://dtum.livejournal.com
"These people should be called what they are, digital grafitti artists with nothing better to do"
Digital Grafitti Artists??? - WTF?
It is sad to see that political correctness has taken such a strong hold with young people. Apparently a generation of Heinlen reading uber-geeks is being replaced by a new generation of nerdy socialists. Doh!
-Bruno
One of the first things I do every morning is check the security sites to see what bugs may have poped up. Then I check the versions against the versions we have installed. Then I take action, either to replace, patch, whatever it takes.
Yes script kiddies give me headaches, but I would rather put up with them than to have my systems cracked and not even know it, or be able to track the problem down.
We were hit a while back by the DNS DOS attack, somehow I missed that report. But I was very happy to find the fix for the problem when I finally traced down what the symtoms were. Without full disclosure, I would still be getting hit with it. Duh!
Full disclosure is a two edge sword, it can cut either way, but I would rather have it.
********
********
Windows has detected several mouse-clicks, restart for the changes to take effect.
This is, of course, why i don't watch TV (except for The Simpsons, which taught me everything i need to know about life ;^) The fact that a show did this to get ratings, and that people went along with it is horrifying.
-legolas
i've looked at love from both sides now. from win and lose, and still somehow...
This article has little to do with "security through obscurity."
So far as I can tell, Ranum didn't say disclosing security holes is a problem. He said disclosing the hole, and along with it providing tools to exploit that hole is the problem that breeds script kiddies.
Do people even read the article before posting it? It seems the submitter was attempting to reiterate the title from the linked article, but failed to see how the new title dramatically changed the meaning.
Maybe its time but guess what... you can go back under your bridge cause this guy didnt stand up to tell them anything about that.
And you have the gall to talk about FUD, pfffttt.
I wouldn't have the slightest idea where to begin if I wanted to crack that system. Don't know what operating
system it uses. Don't know if it's accessible from public networks. Don't know what it looks like even if I
stumbled across it. And I'm guessing that information isn't just sitting around on the internet. THAT is security
through obscurity and it's working very well.
OK, cool. We're safe fom you causing an airliner from augering in. The thing is, someone else out there just might be able to figure it out, even without the source code. There are too many cases of people stumbling onto security flaws in systems to ignore.
The problem with security through obscurity is that it lets programmers be lazy. If the programmers of the air traffic control system are safe to think "naw, no one is ever going to to try that... I won't have to worry about it," then that's just asking for a huge hole in the system.
The simple fact is, the more eyes on the code, the better. If this wasn't the case, why are code reviews a standard part of software development? Why do good software companies do security audits?
Going back to the air traffic control system... I'm sure (or at least, I'm really, really hoping, since I'm hopping on an airplane in a month) that every line of it has been poured over. Not becuase of security concerns, per se, but to catch bugs. Actually, security probably wasn't a concern when they wrote the system, since it's so damn old. But any new system needs to take it into account.
Basically, security holes are bugs. They just happen to be different in that people actively seek them out. It may take longer, and hey, some percentage of the really obscure bugs may not be uncovered. But, security through obscurity will doubtlessly breed even more security holes that will be exploited, since programmers will always be able to fall back onto the "oh, no one will notice that" excuse.
What?
Do you want your server to be the gazelle?
You bought a door lock from a company.. which is more likely to get broken into:
1. I, a third party, purchase every lock on the market as soon as it comes out. I hit the lock with every tool in my house in every combintation that I possibly can. I finally find a combination of tools that breaks the lock. I publish exact details for how to break the lock, futhermore I offer to purchase the tools for anyone who wants to try to break the locks that are out there. This is the first case of the company hearing that there is a problem.
2. I, a third party, purchase every lock on the market as soon as it comes out. I hit the lock with every tool in my house in every combintation that I possibly can. I finally find a combination of tools that breaks the lock. I inform the company that the lock can be broken, with exact details on how the lock can be broken.
Now I undertsand if the company doesn't move you drop a press release that tells there is a way to break the lock. But you don't give the exact details.. the IT industry will push for a fix at that point. When you give out source code on how to break locks.. that is just plain stupid IMHO...
I thought someone said there was going to be free beer!
The flip side is that without full disclosure, we're creating an army of script kiddies and crackers whom we cannot track.
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.
I was waiting for one of you children to raise that issue here.
Maybe we should establish you as a protected class of citizens. "The Child-American Defense League fights to establish the right of Child-Americans to live in a world without Childist restrictions."
Or something like that.
Damn kids these days....
Why the hell is this article labelled security through Obscurity is a Good Thing (tm)? Nothing I read in that article talked about security through obscurity.
;-)
What I read is that he thinks it is a bad plan for people who find vulnerabilities in software to release no-brains tools to exploit them and to do it because it is profitable to them.
He didn't say, "Don't tell everyone about the security problem"; He said tell the appropriate people first, don't do it for your own gain, and finally don't put up a website with a set of tools to exploit the vunerability that script kiddies can use.
Why didn't slashdot label this right is the bigger question? Is slashdot being run by script kiddies?
I am a subscriber to bugtraq (isn't everyone?), and typically, when a vulnerability is found, one of three things happens:
- 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.
- Someone posts a working exploit, having notified the vendor 6 months ago, and never having gotten a fix.
- 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*
What's the distinction between the different "hats"... I've heard of "White Hat Hackers", which I assume is a consultant hired to find and plug up security holes... and then there's "Grey Hat Hackers", which I guess is a script kiddie... what are the others? By the way, first post?
I've personally caught people breaking into my machines with software I wrote that they wouldn't ever think to check for. I have no doubt that security through obscurity works in the real world, where 99% of the attacks people get are from people who figured out how to break into people's machines by reading the INSTALL file of some gnu-autoconf-powered-auto-think-for-them package. If you happened to be running Red Hat lately, you might have noticed that barring an update of your FTP server software you are vulnerable to a very bad security hole. I know 3 people who have had their machines broken into in this way. Do you think every time it was someone with a deep knowledge of how to detect buffer overflows? Of course not! Someone audited wuftpd's source code, found a security hole, and some guy made an automated solution for lazy people to use. Does obscurity give you the ability to be secure without properly thinking through all your protocol designs and security procedures? Of course not. But in the real world, where I happen to live, it will save your ass much more often than it will burn you. So if you are tired of getting broken into, write something weird on your own nobody in their right mind could figure out without your help, and keep your mouth shut about it.
What did you eat today? http://www.atetoday.com/
""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
Only proper security measures will work, if something is obscure it will be found.
--- Simple solutions are always the best
WHOOPS. Sorry.
That should have been "we should NOT smear young ones".
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."
when I read the article, the most vivid impression I get is of Ranum moaning that people working for competitors can too easily poke holes in his company's products. Perhaps, instead of complaining that people are finding the holes, he should encourage his own people to either fix the holes or not create them in the first place?
This has been bugging me for a while now. About 20 years ago (1980 was 20 years ago - yeesh) A SF writer had the foresight to put out a short story about a society where computer use had become ubiquitous, for banking, getting directions, playing games, ordering food, etc. The story centered around a character who had been convicted of a computer crime, was made unable to use a computer (the Mitnick case has gotten me to thinking about this) through operant conditioning (see A Clockwork Orange) and was consequently more helpless than a child.
The reason for bringing all of this up: His point was that in a society that has become dependent on the computer, computer crimes (cracking) would become a capitol offense, deserving of the kind of hostility we reserve for rapists or pedophiles today.
While society currently has some admiration for "those scrappy nerds and their new fangled computers" we can expect a day, sometime soon perhaps, when the cracker (and even the hacker) become the unseen menace, the criminal making sure that porn, copyrights, and dangerous ideas are foisted on our children in the dark corners of the Net.
That said, I do not agree with the speaker's overall point, and IMO security through obscurity is a fundamentally flawed idea.
Oh, and what's been bugging me. I read the story, heck, I'm pretty sure I own the book, but I can't for the life of me remember the author or find the source, I think it may have been edited by Asimov. As most good fiction does, I think the story provides an interesting perspective on the problem of script kiddies today and the implications of their depredations for the future.
THE YEAR WAS 2081, and everybody was finally equal...
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.
Your right to not believe: Americans United for Separation of Church and
This is pretty much the approach taken by OpenVMS Engineering at Compaq (and before that, DIGITAL). On the rare occassion (once every few years) that a security hole is found in OpenVMS, the vendor is quietly notified, and a fix is released as an ECO.
OpenVMS enthusiasts are often criticized for this "security through obscurity" model, but the fact remains that, with very rare exceptions, it has been impossible to crack a default install of any recent version of OpenVMS (short of acquiring the password to a prived account via "social engineering" or packet sniffing). And, by the way, source code listings can be purchased, so this is not a "closed source" issue.
Of course, it helps that OpenVMS doesn't do stupid things like allowing data overflowing from buffers (which seldom occurs anyway, thanks to the extensive use of descriptors rather than null-terminated strings) to spill over to the command interpreter. Why on earth Unix allows such idiocy is beyond me.
So now, faced with Dick's signs that point out their insecure security, Dick's neighbors will stop putting their house keys in easily located places, and the net security level goes up.
They might not be too happy with Dick, but their house is now secure.
Better REAL security than false illusions of security.
Want to learn about race cars? Read my Book
Won't happen as long as software vendors are able to avoid warranties and guarantees of expected service level.
Make the vendors responsible for their software's performance, and perhaps a few of them will get things together. Otherwise, don't count on it.
"The dead do not shoo-bop-aloo-bah." -- Kai, 'Lexx'
Whether security geeks like it or not, the fact is that at any point in time---10 years ago, today, or 10 years in the future---90% of the systems out there will not be secured well enough to avoid "new" exploits. Sadly, many users see OS upgrades as their security patch mechanism of choice.
I believe the solution here is to create a standard methodology for this kind of stuff, which would go something like this:
1) Exploit is discovered and announced in very generic terms. No tools or detailed exploit instructions are released. This could be an "announcement" on bugtraq.
2) 30-day clock starts ticking. Release the tool to the vendor but no one else.
3) If at end of 30 days the vendor has not provided an effective patch, release the tool and detailed exploit info.
4) If the vendor has provided a patch, don't release the tool. At all. Ever.
Premature optimization is the root of all evil
I've known MJR (Marcus J. Ranum) for quite a while-- he was already well into computer security back in 1990 when I first met him. He's not stupid; he wrote the TIS toolkit, set up whitehouse.gov originally, and other such stuff. He probably knows more about computer security than somewhere between 99 and 99.9 percent of the people that read slashdot.
When I read the article, I slapped my palm to my forehead-- "good grief, everyone's going to think he's advocating security through obscurity". He knows better, I know he knows better. What I'm guessing he's saying (I haven't read the text of his speech-- I'd love to see a URL to it rather than all these damn summaries) is that: full disclosure --> people writing tools --> script kiddies with tools causing problems. Now, the obvious culprit in this is the people in the middle writing the tools; note that if you read his words alone and not the article, that's his main target. However, full disclosure is making it much more possible for these people to write these tools. Very few things in this world are pure goodness in and of themselves; this is the bad side of full disclosure, and I agree with MJR that there are going to be circumstances where full disclosure is not always immediately appropriate. In many cases, all that needs to be said is that the bug is possible-- no need to actually provide the buffer overrun exploit code at the same time that you note the buffer overrun. That, I believe, is MJR's point: there is a bad side to full disclosure, and we need to accept responsibility for that instead of just mindlessly chanting "full disclosure is good, security through obscurity is bad, mkay".
---
At least mafia-owned pizzarias make excellent pizza. Compare to Bill Gates.
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.
I think your analogy is helpful.
The ideal response would be for the company to publicly announce a recall due to security probles with the lock (just as car manufacturers do with recalls). They would repair/replace free of charge.
However, they wouldn't give out explicit details on how to exploit this problem. That would be silly, and would obviously encourage the less scrupulous types to take advantage of it.
Thus, you have public exposure, a fix, and no unnecessary information given out to the baddies.
The real issue is what to do regarding companies that ignore security problems, even when brought to their attention.
ShoutingMan.com
--
The big question for me is: Who are the reputable Handful?
I would consider the developer/company who/which developed the code to be most likely reputable or at least interested in fixing it. I would also notify CERT. Some examples:
1) I would notify Alan Cox if there was a network hole in Linux.
2) I would notify Darren Reed if there was a hole in IP Filter.
For both, I would also let CERT know about the bug I found and that I had already informed the authors.
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
That is a stupid arguement. You should say:
(5) So, I **MUST** release the code to the people in charge of updating the linux kernel so thtat they can fix the problem.
There is absolutely no reason to release that code to the general public until you have given the details of the bug to the people who can fix it. Then if they don't react fast enough, send the details to a few key people in the computer security field that can verify the problem and publicize its existence. Only if that fails to get the vendor to fix the problem should you consider full disclosure.
I wholeheartedly disagree. ALL crime, whether it's cyber or meat, should be measured against how much actual harm was caused to actual human beings. Corporate, government and idealistic interests should be secondary to the benefit and well-being of actual thinking, feeling human beings.
-Hentai [in vita non pacem est]
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.
"In the next five years, we are going to move to a counterterrorism model," he said. "It will turn into a witch hunt, unless we stop the script kiddies today."
//
As if there is even the slightest hope of a centralized controlled effort to stamp out "script kiddie" activity. No one can control the internet as long as there is free speech... no one can stop the release of exploits or software as long as people are willing to write them... someone, however, can start a "witch-hunt".
It's not like there haven't been "witch-hunts" before in modern history (Blair aside, I'm thinking McCarthy) and I wonder just how successful that would be given the nature of the internet? I can't imagine a "counter-terrorism" effort doing anything else but causing mass panic and consumption of "anti-hacking" (term used loosely) utilities. I'd have to say that this whole article is nothing but mass-media fodder. Marcus Ranum doesn't give us any really viable solutions I suspect he wants us to pay for them.
--// Hartsock
Live to Code, Code to Live!
We would be giddily working on our security-less machines until one day the exploit became publicized and it took out 90%+ of every machine on the net in one fell swoop.
Also, what does ILOVEYOU have to do with publicly releasing security vulnerabilities? Any 5 year old with a modem could have pulled that one off...
Please, please, please do not listen to this drivel.
Script kiddies are dumb, hackers are smart, and we need to exploit this. If full disclosure is made on both the exploit side and the source of the program being exploited, a hacker is always going to be able to write a patch before the script kiddie figures out how to implement the exploit.
By not releasing the source for parts of Exchange M$ shot itself in the foot by not letting the hackers get to hacking.
bash-2.04$
bash-2.04$yes "Don't you hate dialup connections?"| write USERNAME
The good old tried and tested security-through-killing-people-who-find-out that the mafia employs has always worked well. Both deterrent and remedy.
It's 10 PM. Do you know if you're un-American?
I don't think that causing fatal auto accidents is the real world equivalent of crashing some corporation's webserver. It's more like keying a car or something. Yes, script kiddies are annoying and they can cause quite a bit of damage, but let's try to keep a little perspective on it instead of equating them with murderers, ok?
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
The real problem with script kiddies is not their menacing large, well-funded sites like Yahoo. Yahoo and their ilk have lots of resources they can use to close all the security holes they find.
No, the problem is sites like my amazing.com or Kiro5hin, which are run by an amateur or amateurs and simply don't have the resources to track down every security patch and close every hole.
I was blasted off the net for over a month because of one security hole in the Cobalt Raq server I bought. I had the money to buy the server, but not the time to keep it safe.
Kiro5hin had a staff, but when confronted with the type of attack Yahoo's sysadmins get paid big money to guard against, they weren't able to help. Part of the problem was that they were unpaid volenteers, and I'm sure they - like me - had a boss yelling at them for not doing the work they were hired to do while attempting feverishly to deal with the problem.
This is why the script kiddie is such a big problem in my mind; it threatens what's left of the non-profit, more or less communal/genteel part of the net. I'm as much of a capitalist as anyone, but I still have a special spot in my mind for this kind of thing.
I am all for a policy that avoids any disclosure of security holes. I don't even care if my machine is secure; everything on it is public anyway. I don't want to have to care if my machine is secure, and neither should anyone else who sets up a volenteer or individually-run site for the joy of sharing interesting stuff with the world.
Unfortunately, revenge on the script kiddie, sweet as it might be, takes resources. Yahoo has 'em and can catch 'em if it wants to; I simply don't have the time and don't want to take the effort. So my machine is vunerable, and I don't know what to do about it other than shutting the whole thing down.
A very depressing choice, let me tell you.
D
----
A relative of mine is in the hardware business (the nuts-and-bolts type of hardware). He once showed me the reason why he doesn't sell a particular brand of deadbolt. This particular brand could be removed from its socket, from the outside, without any special tools, by manipulating the lock in a certain way. This behavior is in the lock by design - this particular lock company markets heavily to organizations needing to quickly and easily rekey their locks (think apartment complexes.) It's very easy to remove the lock mechanism from the outside so that it can be rekeyed, at the cost of rendering its security moot in the face of someone who knows how to jimmy it.
If this were the computer industry, I observed, a manufacturer that did something so blatantly stupid would be subject to public ridicule, written up in the industry press for their failure, and made to immediately change their broken-by-design design. As it is, thousands of apartment dwellers are behind doors that are, for all practical purposes, unlocked.
Maybe crooks don't know about the flaw. But if you're the one whose posessions are on the other side of the door, do you really want to take that chance?
"Immaturity below their years."
I wouldn't exactly say that. Teenagers spray paint and blow up mailboxes. By definition, they are immature. It just so happens that technology has empowered a lot of them to think that by performing mischief on the internet they are kewl haxxors. I'd say the above poster was mature *beyond* his age, as many smart and often techno-savvy kids are. But most his age are still tipping cows and giving wedgies.
It's 10 PM. Do you know if you're un-American?
Post a description of the problem to the kernel mailing list and ask for the appropriate developer to contact you over a private channel to get the source.
Admit nothing, deny everything and make counter-accusations.
No, that would be the UNsafety dance, since they were Men WITHOUT Hats.
But, OK, you have a point, skript kiddiez are a problem, they are simply very annoying. Besides, they put food on the anti-virus software writers table, and they really don't deserve it.
What scares me with this guy, however, is that he mentions stuff like the ILOVEYOU trojan as the problem. ILOVEYOU isn't a problem compared to what a highly skilled professional using the same holes that made ILOVEYOU possible for e.g. industrial espionage. It really amazes me that people fail to see this.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Who maintainx the kernel? Which one? Linux? Mr. Torvalds, Mr. Cox, about eight or so other people. Send it to any one of them or any other kernel hacker that you know to be reputable. This isn't rocket science, folks. And I assure you that if you find one and let an appropriate person know, it will be fixed. Quickly.
As for the other programs, I don't know off the top of my head, but that misses the point that I could look it up in 20 seconds on Google or any other search engine if I actually cared. The people who release exploit sources without making that attempt are strictly doing it to make people mad and to get attention. They should be ignored, just like the bullies they are... and they will eventually just go away.
And if the kernel maintainers are busy or on vacation and don't want to deal with a bug right now, posting it to the net isn't going to help a bit, because the people with commit access are the same people who are on vacation or can't deal with it right now. I maintain a tree for an open source project myself. I've been there. When you do something in your free time, sometimes things have to wait. It's much better for it to wait a few days with the exploit locked up in the hands of sane and reasonable people than to wait while people are cracking hundreds of boxes world-wide.
Personally, if somebody put out an exploit for a piece of software I maintain, and didn't let me know about it first so I could fix it, he/she would find his/her personal information (credit card numbers, accounts and passwords, home address and phone number, etc.) mass-posted on hundreds of newsgroups, mailing lists, web pages, etc. Like throwing a sheep into a pack of wolves -- we'd see how long he/she lasted. :-)
Your argument about MS is a good point, but one company's total incompetence at security does not imply that this method is appropriate in a general case. I'd like to think that MS will be more aware of this in the future and be less cavalier about security. I won't hold my breath.
However, the author didn't just release the source to the public. The author contacted them first and made an attempt to get the problem resolved in a civilized way. MS dropped the ball, so the author resorted to more blatant measures. That was reasonable. Releasing the source for an exploit as soon as you find it, without even bothering to contact the author, though, is neither acceptable nor reasonable, and should be dealt with by any means necessary.
Instead of immediate disclosure of security holes, I believe that the originator of a security exploit should first attempt to open a discourse with the maintainer of the affected software. Rain Forrest Puppy discusses such a policy at http://www.wiretrip.net/rfp/policy.html Disclosure of the exploit should come eventually so that we can all learn from the mistake. As someone who is in the security field, I would rather learn from the mistakes of others than subject our customers to the same mistake in our own products because of ignorance.
Because people like me, who run a web server with a few Perl scripts to do certain things, without really being a programmer, need run run the scripts to check certain exploits, to discover flaws in my code so as to be able to fix it.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Bah!!
Kids today have it easy because us late 20-something GenXers suffered for the cause. And now hacking is tres chic these days.
<voice="old-man">
Why, when I was kid, from 6th to 11th grad (that would be circa 1983-1988) I was routinely beat-up and harrassed because I spent my recess periods--and countless hours after school--programming the schools commodore Pet. Ok, I guess I deserved it because I was skinny and wore argyle sox all of the time, and maybe I should have done book reports on other things besides Ada Lovelace, ENIAC and the transistor... but hey...
</voice>
Now it's ultrahip to be a hacker. Look at the exponential growth at DefCon (had to get a hotel in Barstow!!!)
Posers vs. Punks vs. Script Kiddes
Script kiddies are the equivalent of some poser who has 50 bucks and few hours to kill, and thus become instantly hardcore by getting a tribal tattoo around his/her bicept... or maybe even a tongue piercing and bleached hair. Ooo. Bad-ass. If punks hadn't been invented this culture in '75-85, and then pop culture hadn't made punk culture a commodity, nerdy suburban kids would still be wearing Izods and ProKeds.
I hate being introduced by my friends as a hacker. And it's my fault, I should just lie when friends call me to go out on weekends and I'm too busy optimizing assembly code. I think the best thing real hackers can do is to help devolve the image of hackers back to being booger-eating social-skill-lacking losers so that we can have the quiet solitude of our underground handed back to us.
</rant>
---
https://www.accountkiller.com/removal-requested
Actually, any sysadmin or security engineer who knows what he's doing does read those lists/sites. I'm not sure what you mean by "normal folks"; sure, my grandfather who does all his genealogy research online doesn't, but then, I'm not sure he needs to. If you mean "normal" system and network administrators, then I'd reply, that's part of their job. If they're not doing it, then their employer should get someone in there who will do the job correctly.
"You can never have too many elephants on your team."
My problem is with the pre-written, ready to make/execute "demo" code. And if people won't believe that an exploit exists, send a copy to CERT or something, don't post it to USENET...
Yes, the information has to get out, but don't hand a gun to everyone to show them that your bulletproof vest has a hole in it...
My friend and I used to operate a PC running RedHat Linux at a local high school. We remotely administered the machine until the school burned down, but that is a different story...
Getting to the point, a script-kiddie broke into our machine exploiting a buffer-overflow hack in our IMAP daemon. How did we know? The guy, we finally tracked him to France, left the hacking kit in a home directory he created for himself!
It's sad that these script packages give anyone the tools to get into a large minority of machines on the Internet, but the packages do not educate the users.
These kiddies aren't bad, they're not evil, they're just mis-guided. I got into a lot of trouble a few years back in Jr. High. I'm sure I would've stayed on the misguided path had not an older, wiser computer hacker helped me see the light.
We need to spread the following maxim:
1) Just because it's easy, doesn't mean you should do it.
2) Just because you can, doesn't mean you should.
3) Just because you'd like to, doesn't mean you should.
Okay, all three are really the same...but, we need to educate the masses.
I've been hacking computers since I was 10 years old and now I'm an M.Sc. teaching basic CS at university level. What I learnt early on was not to underestimate the level of knowledge my students have. Some of the people are just bloody brilliant.
When I was at high school I used to hold back on showing my skills simply because 1) it wasn't necessary; I got an A in any case and 2) I didn't want to make the teacher look ridiculous by pointing out obvious mistakes.
Releasing useful scripts that easily exploit the bug is much different than releasing useful information to help fix/prevent the bug (even if the solution is to turn off said service until a patch is available). That said, I totally agree that as much information as possible should be released as soon as possible. In the case of free (as in speech) software, some genius might even have a patch ready for the maintainers of Foo when they get back from vacation or the drunk tank or wherever. In the case of proprietary software, well, as much should be done to discredit that model, so biasing the public by inducing a panic can only be a Good Thing(r). Or something like that.
I do not have a signature
I am violating my own .sig here, but I'll live with myself:
Dear Asshole,
There are no flaws in my argument. If a person finds a vulnerability in my system and then quietly, privately lets me know about it, that person is my friend. But if the bastard publicizes that vulnerability so that I become victim to myriad attacks by script kiddies and their ilk, _that_ person is my enemy.
To simplify for the simpleton, if you cause harm to my person or property, then you are a criminal. If you do anything to aide or abet harm to my person or property, you are also a criminal.
Neopets - the best free game on the Int
a compromised redhat machine I saw recently had a root kit installed which replaced ps, but not top, to hide some processes. Now what level of (in)competance do you think that kid had? Probably didn't even know much about what the root kit did, but installed it cause the other kids on irc told him to.
these folks are being given tools, and they use them. they don't know what the tools are doing, nor do they care. if they weren't given the tools, they'd find some other stupid things to do.
But really, neither obscurity nor full disclosure really addresses the issue. The issue is that these holes do exist, and better updating mechanisms must be built into operating systems so that holes (whether they were disclosed or covered up in the first place) can be plugged.
Maybe an active agent on the operating system to check and automatically install new security patches. Because no matter how a certain security hole is discovered and information about it disseminated, they never get plugged fast enough.
cheers,
-o
Exactly. Enough information should be given so that a security expert can find and protect/fix the hole, but code to exploit it should not be handed out. Without someone handing them the code, most script kiddies would be dead in the water. If they're smart enought to figure out how to write and exploit, then they're probably smart enough not to use it for evil.
Will this stop script kiddies? No, someone will make them a script at some point, but hopefully, it will slow them down and give us a little more time to patch the holes.
All this IMHO, of course.
On the other hand, how bad is it that the scripts are out there? As far as I can tell, a lot of sites don't start locking their doors until someone has come in through them. If all script kiddies dropped off the face of the earth today, security would probably go to hell. Would you feel more secure if the sites that kept your credit card info (as an example) didn't have to constantly worry about plugging every little hole that a script kiddie is going to use?
The internet is a hostle place. We are just going to have to adjust to that. Script kiddies and black hats are not going to go away. ever. All the whining and finger pointing in the world is not going to increase security.
If you can't take the heat, stay off the net.
I like to have source code to test a new exploit on my box. I'd much rather verify that I am vulnerable, patch, and verify that I'm no longer vulnerable than just blindly patch my system and hope that RedHat fixed the problem for me.
... or they'll move their spare keys to a slightly different spot, say under a rock a few feet away.
Now, repeat after me, slowly, until you hear a loud 'ding' (the sound of CLUE) -- Source code is not a right. If I don't like it, I will write my own and GPL it.
The Slashdot Sig Virus
Hey, baby, infect me!
-30-
Without disclosure and actual attacks, security is not an economic incentive. It can't be demonstrated to customers, and it doesn't become a product differentiator. The occasional problem that might happen in a world without disclosure are not sufficient to affect the bottom line, in particular since software vendors are usually not liable.
We tried hushing up security holes for decades and it didn't work. In fact, it gave us the Morris worm--the exploits it used had all been well known for years without any vendor bothering to fix them--and VMS pseudo-security. Arguably, the current sorry state of computer security is still the aftermath of that approach.
I see nothing problematic about disclosure of security problems, whether by competitors or anybody else: it's the only policy that objectively makes sense from the point of view of the customers in order to create a market that supports secure products. "Script kiddies", far from being an annoying side effect, are the very mechanism that makes disclosure effective: without the economic threat from their activities, vendors would still have no incentive to fix their security problems.
In the long run, I hope that these kinds of economic pressures will get rid of the snake oil and tinkering around the edges (and that includes Ranum's own intrusion detection systems) and will force companies and developers to adopt tools, methodologies, languages, and cryptographic approaches that address security problems correctly. (Yes, this also means Linux needs to change.)
Amen to that. Simple school trick for all of you though (as I was there no so many years ago) - befriend the most computer-literate teacher in the school. Help him out, even offer to help set up the new lab they're building, or roll out a new program or something. Once you got the green light from someone that the admin knows is tech-savvy, you'll be respected highly for your abilities instead of mistrusted. Anyone with any skill that's young these days tends to be grouped with the script kiddies, which is a shame. Cuz give it a few years, and people will be throwing money at you for the exact same skills.
Code review is indeed a very valuable tool but I do not equate that with open source. Take the group that writes the shuttle software. They have extremely stringent code review policies and it seems to work quite well. They do not open source their stuff. Why? Because nobody else needs to read that code. Nobody else is programming the shuttle.
Similarly, people are not runnning ATC servers on their home PC. But for the sake of discussion, let's say they did release their stuff. Who is going to be interested in poring over that code? Practically no one. Why? Nobody has any use for it! It's also probably written for hardware that you don't have (a VAX perhaps?) Why spend hours and hours poring over this code if you can't even USE it?! You wouldn't of course. Only a few people would play with it for the gee whiz factor. The rest would be those with malicious intent.
In short, I'm glad you are not the Secretary of Transportation.
Yes putting all you eggs in one basket may be dangerous, but it is especially so when that basket is full of holes
As the article said:
The Melissa virus and the ILOVEYOU worm plagiarized much of their innards from other viruses that came before.
And why were these holes not plugged up when the "viruses that came before" were discovered ?
Maybe someone somewhere just doesnt care ??
There are no "grey hat" hackers. There are those who hack maliciously, and with full self-knowledge of their evil intent, and there are those who pontificate, and rationalize their hacking and try to make it sound noble and imbue it with self-righteous virtue.
Fuck 'em. If I am using piece of software, closed source or open, and you provide the keys to compromise my safety and/or security, then you are a criminal who deserves to rot in hell. I don't care what color of hat you think you are wearing. Aryan Nation thugs justify their evil, too. "Gray hat" hackers are talented, but they are masturbating in thrall to their own "power."
The quicker we lock them up, the better.
Neopets - the best free game on the Int
We can debate the merits of disclosure vs. nondisclosure of security holes, but the bottom line is that there will always be motives for hackers to disclose security holes in software. The key motives are publicity and recognition, which appear to drive many of those involved in hacking/cracking. And what better way to become recognized in this community than to be the first to identify a security flaw.
The real question is how to use this in a positive way, and I agree this is largely a social issue. We need a way to (1) channel the energy of the hackers in a positive direction, and (2) force companies to be proactive in filling their security holes.
One way would be to to encourage the following approach: If a hacker identifies a new security hole, they (1) notify the company who's software is vulnerable, (2) tell the company they will publicly disclose the vulnerability after a reasonable "quiet period" (perhaps two weeks), and (3) tell the company they would expect/appreciate an expression of credit/recognition once the company publishes the fix.
At that point the ball is in the software company's court. If they fix the problem (and credit the hacker), then it is a win-win-win situation for the vendor-hacker-public. If they don't fix the problem within the "quiet period", then the hacker discloses the problem, and the company looks irresponsible, and is still ultimately forced to resolve the problem. And if the company doesn't credit the hacker, the hacker publishes their previous communication, and the company looks like thankless scum.
So how do we encourage this approach? We might start by looking at the terms we use to describe hackers. Most hackers would rather be known as "White Hat", as opposed to "Grey Hat" (or Black Hat). In my mind, those that take the above approach (notify, wait, publish) should truly be called "White Hat" hackers. Those that publish immediately (without pre-notifying the company) should prehaps be viewed in a more negative light, and should be called Grey Hat Hackers.
Brief article that it was, an important point which was not covered is how the vulnerabilities are supposed to be reported to those who are responsible for ensuring systesm are not vulnerable? :-)
If I recall correctly, one of the reasons L0pht first went public with their stuff was the the software companies were not responding to reports of security holes in their products.
Granted, releasing tools which make it easy for anyone to exploit a vulernability is not a wise idea, but trying to keep security holes "secret" will only increase the FUD factor for admins responsible for application/OS security.
I do aggree with his point that there is a serious social issue at work here. It has almost become "fashioanble" to deface websites, this digital vandalism though is more far reaching than spray paining dirty words on buildings, or breaking school windows on weekends.
And while the actions of these people in defacing and launching DOS attacks result in lost business etc, I think that once goverments and terrorist organizations really get into this sport of stuff, it could get much much worse.
It's sad to see such a powerful force for positive social change be fubar'd by a bunch of adolescent wannabe's trying to impress their peers.
Okay, so I am a UPA Troll, but that's different
Going on means going far
Going on means going far
Going far means returning
I've always wondered who "script kiddies" are. I mean, hell, I have installed Linux on my machine and ran a few exploits, but didn't every get anything to come out of it.
I *tried* to be a script kiddie once. You just can't do it. Even script kiddies have the knowledge it takes to change C code or write up their own program.
I don't think that the "script kiddie" as we know them, or presume to know them, exists. I believe that they are actually system admins that get tired of the work they are doing and take it out on some other system on the net.
Besides, I've yet to see any credible source *name* someone as being a "script kiddie". And to think that I thought only "script kiddies" got caught?
Did I miss something here or do script kiddies really exist as the 14 year old geek-wannabes we think they are?
It wasn't until someone actually wrote some code that the Great Beast was forced to roll-over and grumble. Corporate entities do not respond to warnings. Corporate entities only respond to crisis. There is no crisis until someone codes the bitch.
g -of-Hack.html
A very amusing example of this is buried amidst the Jargon File pages:
http://www.tuxedo.org/~esr/jargon/html/The-Meanin
Regrettably, "killall" would probably stop this hack in its tracks now, but it's still very amusing reading.
I think you make a good point. I think "Security through obscurity" really does work in many many cases where it would be disastrous to release source or publicize exploits. Think of something like the air traffic control system. I wouldn't have the slightest idea where to begin if I wanted to crack that system. Don't know what operating system it uses. Don't know if it's accessible from public networks. Don't know what it looks like even if I stumbled across it. And I'm guessing that information isn't just sitting around on the internet. THAT is security through obscurity and it's working very well.
I think the "many eyes" thing works great for something like Linux because there actually are lots of people working on the source code. But those benefits are lost on things too small or boring to attract enough developers.
Ok, so ssh will keep the script kiddies from reading your password, and telnet won't. That doesn't help a bit if they've done a bind exploit, gotten root, used a rootkit to replace ssh, and now own your server.
I love vegetarians - some of my favorite foods are vegetarians.
And I guess shooting you is OK so it forces you to Get A Clue and wear a bullet proof jacket?
Crime is crime, and no excuse in the form of "it's only done to show that you haven't spend countless hours and gazillions of bucks securing yourself". It doesn't hold in court for theft, rape or murder. Why on earth should computer crime be an exception?
-- Abigail
As explicated, yes, it is more complete, but I disagree with your assertion that it is more "mature," as I hold exactly the same opinion regarding "grey hat" hackers as I did when I first posted in this thread.
IMHO, it shouldn't be necessary to spell out all steps of a cognitive process, especially on a forum like Slashdot, where, ostensibly, geeks rule the roost. A geek should be able to surmise the obvious elements, and ramifications, of a simple argument, without it being explicated. In other words, I knew that someone would bring up the "crowbar" anaology, but I hoped against hope that no one would, as its rebuttal is so self-evident (my previous message) that it seemed silly to preemptively counter it.
Neopets - the best free game on the Int
Then theres always the guys in the brown hats who end up getting in trouble with MAPS ecause he didn't get a guy in a white hat to secure his mail server from some assh0le advertiser in a Dumb hat who bought some unholy bit of spam software from an even bigger assh0le in a black hat
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
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
which makes offering such a service much more valuable. Instant market. And I'm not talking about bugtraq, something a bit more user friendly, ie. this is your specific problem and these are the words you type in to fix it.
--
+&x
All I read was an "expert" whining about people that have more skills than he/his company does. I
'm sorry, but it is easy to lock down a box, but on the same note... if your web server is the same as your accounting database server... you deserve to lose everything when it get's nailed. Your internet equipment has to be outside the protected zone.. if it isn't then your company is just plain stupid.
I can see problems like kuro5hin happening, but no script kiddie is gonna take down ibm.com .
We are currently at a crux of the digital civilzation... we have technology abounds and very few that actually know how to administer it. And we have a large amount of people masquerading as those that know how to administer it (MCSE's, 60% of all the sysadmin's out there, etc..)
In 10 years things will be different... I see more chaos coming, but more effective filters or private "internets" will rise to meet the demands.
If you want to gague the chaotic levels of the internet in general... just spend 1 night as an op in any IRC channel.
Do not look at laser with remaining good eye.
If security in the net is to be effected by the use of cryptography and robust authentication then he's plain wrong. As it is, these algorithms need to be reviewed and attacked by as many people as possible and keeping them secret is not going to help a bit.
Security by obscurity vs Security by disclosure...
With Security by obscurity usually a cracker discovers the defect and releases an explote.
We discover the defect after the crackers efforts has resulted in mant victoms.
With security by exposure the defect is descovered and made public. Now it becomes a race. Who will win. The patch or the cracker?
In the case of Linux the patch. The cracker won't bother. His efforts are for the long term not for a short term. A SysAdm will patch his system and relase the patch in a short time. The SysAdm is motivated not only to fix the defect but to make sure it stays fixed (so he dosn't need to fix it on a future update).
In the case of Microsoft it WAS the cracker as Microsoft didn't take it sereously but now they do so it's an even race.
Any time a company dosen't take the issue sereously the cracker will win. The public also wins as this provides a hot poker to anyone who would not take security sereously.
If the company prepetually fails to patch defects the company becomes known for defects and profesionals are discuraged from using the defective products.
It also helps in monopoly cases... to prove a lack of consern for the costummer.
Security by disclosure wins out...
After all.. the consummer can't know if a defect is being ignored if the defect isn't disclosed publicly. If a hacker dosn't expose it sooner or later a cracker will explote it... the exposure just gives the good guys a better chance and the costummer a heads up..
I don't actually exist.
Yeah, right.
The problem remains that systems are still being shipped with security holes you could drive an 18-wheeler through. This is unacceptable behavior on the part of manufacturers.
What we need is product liability for this sort of thing. A few billion-dollar lawsuits will make Microsoft, Red Hat, and VA Linux get their act together.
Yep... back in HS I erradicated a building-wide infection of a virus, and earned rights to virtually every non-administrative computer in the school, most importantly the library PC with a 14.4 connection to the 'net.
_sig_ is away
I have a quick quiz for all of you.
How is my house more likely to get broken into:
1. I have a door with a broken lock and I don't tell anybody.
2. I have a door with a broken lock and I put a sign in my front lawn reading, "I have a broken Brand X lock. Can somebody tell me where to get a new one?"
Sure, security through obscurity isn't so good when it's used by itself, but it certainly helps.
Nope...
Need to test the fix or you might as well not bother.
In the mean time.. an explote is being writen
I don't actually exist.
I'll change the admin login on everything to 'nimda', and make all the passwords 64 characters long!
In all seriousness, without real security measures, the real crackers are going to have an easier time of it than the script kiddies.
- chris
- chris@unbeliever.netspam
- i hate capitals
- aim:arikel6000 / yahoo:blackrose91
If your assertion is right, one of the biggest stregths of the opensource operationg systems will cease to exist as their market share increases. The fact is, a huge proportion of computer users don't, and never will, keep track of security issues.
So, if/when Linux has an 80% market share, any bugs that are discovered are going to remain unpatched unless there is some sort of automated system (which, as you pointed out, is not necessarily very effective).
The problem seems to be with having lots of non-tech savvy users, not necessarily with open/closed source development.
If the users aren't patching their software then what we need is better automated patching systems. Maybe that should be a fundamental part of any server OS.
Interactive Visual Medical Dictionary
I don't know about the rest of you, but I'd rather have some idea of specific things to watch out for on my networks rather than having no idea. I prefer a product that's had a few holes fixed rather than one that has who knows what...
You encourage script kiddies by treating crackers like geniuses in the media. True. But by not reporting security holes, we allow something bad to get worse [see: MS Outlook]. Either way you're hosed. http://www.ridiculopathy.com
http://www.counterpane.com/crypto-gram-0002.htm
Could you imagine if there was a 'buildup' of undiscovered exploits? A sudden onset of cracker activity in the US or overseas could bring the economy to it's knees.
IMHO the continous tightening of security in response to crackers is a good thing.
love is just extroverted narcissism
Danke.
I'm cool like a fool in a swimming p-p-pfft-pool
Just dont code the bitch. Your neighborhood harassed admin will thank you.
Amen to that. Script kiddies are just that -- ethically impaired children who might know just enough to install RedHat and launch a script from the commandline after having it explained to them ten or twelve times on some IRC channel. Very, very few of them have the knowledge necessary to build their own tools.
I'm all for full disclosure in much the same way that I am all for well-regulated gun ownership. Keeping the info flowing is one thing, but it's quite another to mass-distribute cracking software to script kiddies, just as there is a difference between licensing adults to own guns and just leaving a case of handguns in a high school locker room.
Proud member of the Weirdo-American community.
That may not have been true for the MIPS release, but the Ultrix at the time was BSD 4.x, I think 4.2...
If you're not part of the solution, you're part of the precipitate.
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
Jon Erikson, IT guru
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).
The big question for me is: Who are the reputable Handful? When you limit it to some arbitrary number, decided by whoever finds the bug, you have different gradients of information in the field. THat is, some know, and others don't. You leave it to be a judgement call, and everyone gets screwed over in the process.
Then you said...
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.
Fine, all well and good as long as you can adequately measure 'Malicious'. All Rooting, sniffing and exploiting is not always malicious. Hell, Security folks who find vulnerabilities would be out of work. The boys and girls who find the bugs in the first place would be incarcerated. (That would at least solve your security-holes-for-the-script-kiddies problem.) Malicious is all dependent on the act and who's view you're looking at. I may scan someone's box without malicious intent, but they may think its terribly intrusive and serving only a sinister plan.
Witty quotes suck.
I can see this falling on a lot of deaf or even contemptuous ears in the gray hat community. If information on a security hole is released and someone's just too damn lazy or stupid to plug it or get someone else to, that's their problem.
--
--
What? WHAT?!! Oh.
-- the demiurge
We already tried security through obscurity; it roughly translates as "trust the vendors to do the right thing". I'm sure no one is surprised to find that it doesn't work.
The first full-disclosure lists were founded by sysadmins who were frustrated at the lack of response by vendors, as a "self-help" resource. Some of them even started out as "partial disclosure" lists, thinking that vendors would wise up and fix their bugs. Did it work? Nope.
Heck, even in this day and age, vendors are still stupid. Every so often, a bug gets posted to BugTraq without an exploit, and the vendor gets all pissed, calls the submitter a liar, and threatens a slander lawsuit. The only way to shut them up? Publish the exploit.
That's when people like Ranum get all pissed because the poor submitter defended his honor after being slammed in a public forum. Well, cry me a river.
The current situation isn't ideal by any means; I think exploits shouldn't be posted except in cases of flagrant irresponsibility or hostility, just as one example. But let's not pretend that it's irresponsible, or even immoral. It's the lesser of two evils.
If Marcus Ranum wants us to stop publicizing cracks, then he had damn well better be ready to deliver a guarantee that vendor response will be better in an age of secrecy. Can I sue him if a vendor sits on a report and doesn't fix it for six months, and a cracker uses it to trash my system?
Until that happens, get used to full disclosure. It isn't going away as long as the USA has a First Amendment.
Has anybody else noticed the different way disclosed security holes and new virus warnings are treated? Crackers and viruses are capable of similar damage to systems and both enter a system in some disguised manner. Yet, when a security patch is made available there are few takers and little fanfare, but when a new 'Love Bug' variant crops up, it makes national news. There are companies that make a fortune selling software to combat viruses. When was the last time you saw somebody run a Norton Live Update to fix a Microsoft security hole in Outlook?
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.
My UID is the product of 2 primes.
It's the very army of script kiddies and hackers out there that are FORCING major corporations to tighten up their code.
Amen to that.
Lets suppose a hole exists. Who do you want making it visible, and forcing it to get fixed ? A horde of grasshopper-minded 3L33TZ who are usually annoying, but rarely as dangerous as they could be (given the inclination), or someone who is secretive, efficient, and trying desperately hard to steal something useful.
The current SotA in security is pretty low. Major corporations use Outlook, and don't understand why this is bad. ISPs leave SMTP relays and routers wide open. We need to fix this stuff, and we need to fix it sharpish, lest something really damaging happens.
If the cost of forcing the corporate world to Get A Clue, and to employ some righteously clueful admins, is inflicting them with a plague of Script Kiddiez, then that's the price we're going to have to pay until we get it sorted. Nothing else seems to have woken them up.
Moses needed to whack the V1.0 sprogs when his plague of locusts didn't convince Pharaoh. Pay heed to the plague of K1DD13Z, or your favourite Athlon will be next !
Standard rule of risk analysis seems to be: Human Life Risk, Financial Loss (data corruption/loss), Privacy, etc...
But from what I've heard, nobody seems to care about tracking down crackers unless it involves the first two...I'm merely suggesting that Financial loss (and life risks of course) shouldn't be the stopping point. (you can order them whatever way you feel...just hunt the fsckers down.)
...However, those using Outlook in Exchange Server using the Messaging Application Programming Interface "don't have anything to worry about."
Arrgh. Not being vulnerable to one particular exploit is NOT the same as being invulnerable to ALL exploits.
I think you are very right. The problem is not the script-kiddies who do minor damage with well publicized exploits, but ill-intentioned competent individuals who have a private stock of exploits. Accidentally run into some anomalous result of an accidental bug. Use machine-code level debugger to discover what the code actually does (enough difference so that having the source is actually a liability). With its history and habit of applying band-aids over large holes, you know there are some very juicy "undiscovered" exploits.
Ever since whoever got a Pulitzer for blathering about the Hindenberg (apparently caused by a bad choice of paint instead of the hydrogen gas), the media has been trying to go it one better. I think I'm right on this, but flame me if I'm wrong.
Maybe you are preaching to the choir, but it is much like little raindrops attacking big mountains. It's slow, but the relentless pressure does in fact move mountains.
It was on the basis that I was dirupting and potentially damaging their computer system.
:))
Wait til they find out i upgraded the ram in a few other ones
A lot of these people understand very little. A friend of mine ran into problems at university because she copied a program used for her course from the university network. They found out, and despite large letters on the about box saying "Freeware - Please Distribute Freely" they told her that "you cant just copy a computer program" and asked her to return the cd.
Michael,
As someone that has been doing IDS for the past three years, I can honestly say that I've tested *EVERY* IDS system out there,commercial and freeware. Netprowler, ISS, Shadow, Snort, Dragon, etc etc. Of all the commercial products that I have tested, your product, Network Flight Recorder, returns the MOST false positives of ANY commercial IDS. Even more than Cisco. Your commentary in recent weeks regarding network security have been way out of line, without merit, without knowledge, and done with a complete disregard for those of us *professionals* in the network security business. You of all people have absolutely NO place to spout off your verbal garbage and flame people who report exploits and who develop the tools that help the rest of us further the understanding of TCP and IP behavior in relation to computer security. If it wasn't for these people your company wouldn't exist, you know this. I doesn't suprise me that you've been making the commentary that you have been lately. Considering that you have no viable marketshare for commercial IDS compaired to ISS, Axent, and Security Wizards. You have DONE NOTHING to HELP the security community other than to mount your high horse and proclaim yourself as the security guru of the 21st century while belittling those of us who bust our asses every damned day trying to keep the journeyman hacks out. I'm more inclined to listen to people like Steven Northcutt (the god), Dave Dittrich, Randy Marchany, Judy Novak, and others, that have done nothing but bust their asses trying to educate Network/System Aministrators and corportate america about just HOW valuable security is. These are people that have taken their time to to instruct those of us in the security world what these tools are, how they work, how they are utilized, etc etc. These are people that I respect 100% because they are in the trenches every day getting their hands dirty. How dare you insult them and us. What have you done to further the growth and understanding of the security community? Other than sell a sub-standard product that doesn't perform as advertised. What books/papers have you written for your peers to critique? What have you done to promote growth in this field? What have you done to educate the public? I chose security to be my bread and butter and adrenaline rush. This is something that I will teach my kids. You've obviously chosen to market kludge
Security through obscurity has been proven not to work through practice.
We aren't disclosing holes just to the kiddies, we're disclosing it to everybody willing to listen. That means people can know when there's a problem, to which they have every right. Otherwise if one person found this hole, that information will get passed on and on until you get cracked and have no idea why. Security through obscurity is only appealing to lazy sysadmins who don't want to bother with actively keeping their system secure (by visiting bugtraq etc.) and instead want it to be done passively (Microsoft releases a new SP) This is no way to maintain a server and thus no way to look at security.
# debian/rules
1)Find their IP 2)Track it back to their ISP(through IP allocations) 3)ask ISP for address for use in informing the user of legal charges 4)drive to their address, find the kid hunched over the pc (yeah, the nerdy 12 year old chuckling because he thinks he's so 313373) 5)Kick his ass. 6)Repeat as necessary.
====
Crudely Drawn Games
If there weren't so many security holes in the first place, they would not have to release security fixes regularly.
Yet so many of the same kinds of problems are still with us! Things like buffer-overflows, for example, have been known about for YEARS! And yet, we're still getting exploits of THESE on a regular basis. Why?
I would suggest it boils down to motivation.
As long as it is easier for people to keep on doing what they are doing, than it is for them to change, they will not change.
They lack the motivation to change:
What if MicroSoft had to send a check for $50 to every person whose machine was impacted by the Melissa virus, or any other security hole? I suspect they'd have a much greater incentive to locate and fix security holes.
Imagine, a whole new market would appear for tools that would help developers to locate and fix common security holes, and there would be motivation to actually USE them.
There was a concerted revolt, a few years back, by customers against copy-protected software. Customers voted with their wallets, and the companies, begrudgingly, acquiesced. I believe buggy software will continue to be developed for just so long as we, as consumers, continue to accept it. Walter Kelly's Pogo put it well: "We have met the enemy, and he is us."
hypocrisy - The practice of professing beliefs, feelings, or virtues that one does not hold or possess.
No.
--
I think there is a world market for maybe five personal web logs.
I'm sure we all know this but it's a well documented fact that companies fix publicly known security holes MUCH faster than publicly undiscovered (but known by the company) security holes.
I suppose the question is which method does more damage?
With publicly known vulnerabilities you get a lot more script kiddie attacks but I would bet there are a lot fewer serious attacks due to the fact that sysadmins should know what to look for. On the other hand if it's not public knowledge the amount of serious attacks are probably much greater. If the public doesn't know about it then sysadmins don't know how to prepare for it or monitor it (if they can) untill a fix is released.
-Zane
This sig is worse than my last.
It also would then expose the fact that the crude level of security in Unix-like operating systems is inadequate, in that the only information left vulnerable is the only information with value. If the User's data is destroyed, anything else on the hard drive is just the stuff that came off the CD-ROM.
How about the password file? And root access would allow you to do much more damage. Besides, User data is usually backed up anyway....
The simple fact of the matter is, anyone who really wants to examine how a security method works only needs to get a copy and run it through a debugger anyway.
:)
Script kiddies are something of a necessary evil. As annoying as they may be, they are much less dangerous than someone who has a real purpose in cracking into a site... and I would rather a thousand script kiddies force me into keeping my security tight than one "real" attacker waltzing in through a hole that I didn't know about - because I don't have the time to disassemble the binary, but the attacker does.
That said, script kiddies still annoy me.
All operating systems suck. Some just suck less than others. (and some are virtual black holes)
It's already bad enough as it is. Everytime a new exploit comes out, I'm dropping EVERYTHING to install the patch. Inevitably, for the next few weeks, I'm on the phone with 2-3 sysadmins per day informing them that their site was broken into and used to crack other sites (including unsuccessful attempts on mine). What's it going to take to get these guys to start taking security seriously? If these people would get off their butts, script kiddies wouldn't have anything to crack. I remember talking to one admin who simply sighed and said, "again???".
Yeah, yeah yeah, I know, we're all busy. I'm just as busy as the rest of you. It's about where you prioritize your time. I'd gladly get a bit behind on my e-mail to test and install a patch rather than spend two weeks recovering a server (or a few days at the local FBI field office trying to explain why my server was used to send death threats to the president).
--
Quantum Linux Laboratories - Accelerating Business with Linux
* Education
* Integration
* Support
*Condense fact from the vapor of nuance*
There is a conflict of interests at work here:
Full disclosure is suboptimal because people have better things to do with their time than upgrade and patch software. No disclosure is suboptimal because there is no pressure on software vendors to fix holes.
Full disclosure works well with stable software. Eventually bugs get fixed and the continuous public review will have created a secure product which can be used for years and years.
It is with rapidly changing software there is a problem. And in these days where "internet time" is a valid excuse for anything, rapidly changing software is what we have lots of. For this, we need a good idea for how to strike a balance between the two extremes, full disclosure and full secrecy.
One idea is to have a "waiting period". When someones discovers a security problem they inform the vendor but wait some about of time before informing the public, say 1 month. That way not only will a fix be ready place when the problem is publicized, but frequent upgraders may already have the patched software running. The software vendor, knowing that the problem will be publicized at the end of the waiting period, still have an incentive to get it fixed.
Of course this doesn't help the masses with years-old software. Someone please get an even better idea!
/A
man, all you slashdot people are completely nuts.
open source this, free software that, I want to see the source or I refuse to use your software.
but then the minute someone starts distributing some dangerous source, holy shit, this is a terrible disservice to the community.
did you ever think that if you read bugtraq and you see a brand spanking new bug that someone discovered and exploited last night - if this bugtraq post contains complete workign source for an exploit and complete instructions on how to use it - then you can turn on your machine, look at the bug, look at the source, and make your own fucking patch? if youre running a machine on the internet and you have the capability to defend it from attacks by fixing source, and someone is GIVING you, for FREE, all the knowledge necessary to fix this bug and assure yourself youre no longer susceptible, its youre responsibility to fix it.
don't bitch that vendors arent fast to respond, dont bitch that these exploits are dangerous and should not be distributed. the fact is, they ARE distibuted, and instead of complaining, you should be really, really obscenely happy that whoever writes these things is nice enough to tell you about them instead of just rooting you over and over.
Shine on, you crazy diamond.
I find this story vaguely hypocritical considering Slashdot obscured their source code for about 3 years to maintain security.
--
I think there is a world market for maybe five personal web logs.
Security holes need to be shown in order for people to protect against them-however, what would happen if hackers stopped writing tools and distributing them to script kiddies? By their very definition, the kiddies wouldn't be able to write their own tools from just knowing about the hole. Why not just release a patch and some documentation about the hole? This would slow down the problem, at least.
Colin Winters
Sniffing has its place as a valid administrative tool, but so does exploiting, hacking, deep scanning, etc. Running a ICMP ping flood script against your own server has a valid role, but running it against Yahoo is malicious IMHO. I think you can apply similar qualifications to sniffing...
Sorry if I seemed a little anal with the sniffing bit...I just included it because it is an action that many scr1pt k1dd135 take on cracked boxen.
Documenting the exploit isn't the same as posting ready-to-build-and-run source code. Describe the exploit on a packet-by-packet level, and forward it to Cisco, CERT, and other appropriate security fora.
Once you've given good, solid information that anyone with good knowledge of TCP/IP can understand and verify with a moderate amount of effort, you've done your part. It isn't your job to "prove" anything; if you get told "put-up-or-shut-up" then just move on.
OK, I guess you're right in that. The only use I've had is to see if rm -rf * written with some cute stuff around in a search box would erase everything.... :-)
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Your post made a huge amount of sense to me, and after thinking about it, I have this analogy...
Not posting holes in vendors products is like not telling anyone that the X model safe from Acme Corp. is susceptible to being broken into by knocking three times on the hinges, hitting the dial with a hammer, then using a stethescope.
Not telling people about your security setup is like not publishing your building plan or telling people the specific location of the security desk with all the monitors.
The first should be widely publicized. The second should be kept as secret as possible and changed occasionally just for good measure.
Need a Python, C++, Unix, Linux develop
Some companies won't fix the hole, even if it's widely known. They only respond to huge masses of complaints generated by sysadmins running a script and noticing it works.
I think publishing a script with the announcement of the hole is irresponsible. After a month or two with no fix, publishing a script is reasonable.
Need a Python, C++, Unix, Linux develop
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?
It may be true that nobody had heard about them, but that doesn't equate with them not occurring. Before the full public releases, if somebody took your machine down using fragmented IP's, it was chalked up as random flakyness. If your Win9x passwords got cracked, you didn't know how they did it. Nobody knew these expoits were going on because nobody had heard about their existence.
Also, before public disclosure, the only people who could use them were probably much more talented than the average script kiddie, and therefore probably fairly good at covering their tracks.
Just because you don't know about an exploit doesn't means it doesn't exist. That makes about as much sense as burying your head in the sand.
>Would you rather a giant (but pitifully >unskilled) army in front of you, or one very >skilled assassin behind you?
I might get lucky and take out the assassin. Someone in the army of morons would eventually get lucky and take me out.
the fact is, however, that if youre on the internet, you have a responsibility to protect yourself.if your locks suck, thats your problem, not mine, not the hackers writing warez, not the retards runnign these warez against every machine on the net. dont like it? get off the internet.
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
...and how does that make us 6 digit users feel? Pretty bad, that's for sure.
- - - If the sun is a star, why can't I see it at night?
Security through obscurity is great for systems that have little appeal to most developers. Think about Tandem's operating system. Very small developer pool. Tiny when you consider most people don't have the hardware at home to even compile or run it. Now they open source it. How many friendly eyes are going to be poring over code they can't even compile? Not many. How many unfriendly eyes are going to be looking for holes they can use to gain access to insurance companies, banks and stock exchanges? Probably more.
I don't know whether full disclosure is a good idea or not, but I do know that this whole argument is specious and devoid of merit or even real meaning. The fact is, the only way to really KNOW whether full disclosure is better or worse in outcome than hidden reporting would be to set up two, otherwise identical, non-comminicating populations one of which used full disclosure and the other of which used hidden reporting. Measure the relative cost of maintainance and repair after attack in both and then you know for certain (unless the two are so close that there is little to choose anyway).
:-) the following:
This is obviously impossible.
Your moralistic reasoning is a poor third choice in this imperfect world (yes, third choice). To discuss this topic even remotely meaningfully you would have to know (and Disclose!
1) How long is the delay from disclosure to fix (min, max, mean or equivalent other distribution characteristics) for both approaches?
2) What is the usage curve for script kiddies after public disclosure?
3) How likely is the flaw to be detected and circulated amongst the "black hat" community, what probability/time curve does this follow?
A fourth issue, which I will simply skirt over is how long it takes maintainers to apply a publicized security patch? The answer is usually far too long (going on never). Whether this is because of overworked/lazy/incompetent administrators or clueless managers or greedy, penny wise, pound foolish companies is a whole other question (left as an exercise for the reader). I will say that I strongly suspect that the reason for the prevelance of script kiddies is poor pushing appaling avarage administration WRT security, not the availability of cracker kits (to which, most of the time, defenses are already available but not implemented).
Unless you have answers or reasonable approximations to the above questions and are prepared to do the (difficult) math, you are simply venting hot air (as are your opponents).
If you can prove your point, please do so. If not, please go fart somewhere else, it stinks enough around here already.
Thank you, have a nice day.
I'm impressed that someone thought that was "Insightful" - it was definitely one of my more disjointed posts. Oh well.
Your right to not believe: Americans United for Separation of Church and
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!
Quick! off the top of your head. Who maintains the kernel? Who maintains BIND? Who maintains ftpd? Who maintains klogd? Who maintains the gravis sound drivers?
Maybe the kernel maintainers are busy, or on vacation or just don't want to deal with a bug right now.
If I founf a bug, some cracker somewhere else may have too.
Now it's a race. I'd rather freak the public now and have them close a port on their machine or down/upgrade a daemon than just hope the Powers That Maintain The Foo act quickly to patch foo.
Look at MS. A bug was found that allowed password snooping. MS was notified. Months passed with no fixed. Then the author released the source exploit to the public. Panic ensues. But lo and behold MS comes out with a patch almost immediately thereafter! Panic got something done. And squashing bugs quickly is what needs to be done.
Notify the company/maintainers/etc. Include in the notification that it will be made public on a specific date. This gives people time to create a fix and start distributing it. One of the big problems with press-release notification is that the patch is not normally available for a day or two or week or more, so you've pointed everyone at a hole that can't be fixed for some period of time.
Now, for cases where there is a workaround or easy fix you might want to just release it, or give a short time-span before release (a day or two).
The general idea is that knowing that the information will be released is a strong incentive for the company to have a fix ready, or better yet to have started distributing the fix, either discreetly (no information on the exact exploit of the flaw) or openly.
You are a fool, sir. Suppose someone discovers an exploit in a program you're using. They do the responsible thing and privately tell the vendor. The vendor sticks their fingers in their ears and goes "La, la, la, I can't hear you." What then? How is our responsible exploit-finder supposed to tell you without telling everyone else? Now, if the vendor does the Right Thing and releases a patch promptly, then there's no problem. But experience has shown that many vendors won't get off their ass until you light a fire under them. And the only way to do that is to publish the exploit.
--
--
Do I look like I speak for my employer?
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
Microsoft, through 'windows update' releases security fixes reguarly. They attempt to have *everybody* get the fix at once. I doubt this works very well.
Maybe I'm stereotyping here, but right now, I'd say most Linux users read Slashdot/Kuro5hin/Freshmeat or something similar, so when someone discovers that you can destroy a Linux box just by connecting on port 7, everybody finds out right away, and can fix it quickly.
--
when the rain comes, they run and hide their heads. they might as well be dead.
'Security through obscurity'?
Is the man in the middle ages?
What kind of drooling idiot is this? What kind of idiot security model is he advocating?
Internet security is like building a dam, unless you plug every damn hole the whole thing will come down on you.
Does anyone see a future when every software manufacturer can be trusted for the security of their product (and more importantly, tell you immediately when they've found a hole)?
I don't.
Please explain to me how running any local/remote exploit-of-the week and getting yourself a root prompt on the exploited system helps you discover flaws in your code or otherwise allows you to fix the problem.
A clear, concise description of the flaw and what should be done to work around it or fix it should be given, but in many cases we do not need root exploits released like this.
If it's ever necessary to distribute a tool to determine if you are vulnerable to some bug (in case for whatever reason it's not immediately obvious), the only thing that should be written is a tool that says "yes" or "no". Sure, somebody will be able to look at the code and figure out the nature of the bug, but the point is that the "exploit" itself cannot be instantly used by thousands of script kiddies. If it's necessary to distribute detailed information/code about a vulnerability, at least do so without providing an out-of-the-box exploit to any kid on the 'Net.
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
IAAL,BIANLY
Trying to apply a real world analogy to the digital world is like designing filesystems like file cabinets which in itself is a bad analogy. Imagine a corporation that sells padlocks. You buy a padlock for your home, your neighbor buys one, pretty soon, 60% of the people in your city have one, then the state, then the country. Now the locks are everywhere. A thief by trade discovers that all the locks open with the same key. The keys look different when examined, but they all have the needed notch to open any of the locks. The thief will keep this secret quiet most likely since it is an unknown. He will break into homes with those locks and have his pick of any home using them. He can go one at a time and steal whatever he wants with ease. Now let's say a customer reports to lock maker corporation that he noticed the problem. The corporation says, oh, it is just a bad batch of locks, we only sold a few with that problem. We will send you a new lock. The customer receives his new lock and tells a his friends/neighbors. Some of them hear it and also receive new locks. But eventually, as communications theory goes, the lock problem won't go much further outside the center individual. It may even be ignored. The corporation will not alert its customers since it would cost them both refund/replacement money and future sales. They would rather wait and let you buy their next product in a few years than give you the safety you thought you payed for. The might even use the info in a watered down form (diverting their responsibility) to sell the latest model in a few years. Now suppose the thief made the information public. Now the corporation has to respond to its customers for the low quality product they sold them. Now customers will be aware of the problem. However, more thieves will also be aware of the problem. However, the customers have a chance to respond to the danger they believe they are safe from. The incident costs the company a lot of money and increase the number of break ins that would have occurred if customers ignore the warning. The corporation selling the product hurts financially. If the customer doesn't respond to the warning, they hurt financially as well since their house may be broken into. But the customer has a chance to respond where if the information is not disclosed, no such chance exists. The company won't tell. I believe that is what this whole criticism of hackers is about. It is keeping sysadmins on their toes. It is keeping companies on their toes to fix their products and test them better. That is what is making the industry angry. I believe their are a lot of sysadmins who should be saying "May I help you", not running a company/school network. So the new version of that product has cool and easy to use interface, do you know anything about what you are configuring? Do you keep yourself well informed on security issues or depend on a vendor or an "it won't happen here" policy to save you? If you are, you should choose another line of work. The benefits to consumers and computer science in general are enormous when security systems are open to public scrutiny. A "black hat hacker" may not be stopped since he is capable of finding his own exploits and will take the time to find and code tools to exploit them. All the other individuals who attempt to wreak havoc, steal information, etc. from your company will flock to these premade tools. Premade tools encourage many who wouldn't attempt such a feat for lack of skill/tools to wreak havoc. But the premade tools also cause the rest of them to gravitate towards tools that because the exploits/tools are documented publicly, provide you company/school a defense against intrusion and a easier path to detecting intrusion so that damage and theft can be minimized if not eliminated. Most of the time, the information will cause the individuals to gravitate around the exploit, preventing them from using their creativity to locate new security holes and build tools themselves that are significantly more difficult to detect. It prevents in that they are less likely to think outside the box once they have been contaminated by the contents of a publicly known exploit. Openness is the only way to be secure. But it will cost unprepared organizations and sysadmins a great deal of money and trouble. But maybe those sysadmins should be working at McDonalds anyway.
different people have different opinions about disclosing security holes. Clearly, if you know about a hole, disclosing it will warn people of a problem that bad guys might already know about, but it will also tell the bad guys about something they might not know about. There is no right answer to what the best policy is. In one circumstance it might help you. In another, it might harm.
But, if you believe in free speech, and freedom to explore, and in preserving diversity of opinion, live with it. I will note that the folks who complain most bitterly about disclosure are the companies who sell the buggy software, not their customers who are at risk.
once the public is sophisticated enough to know the difference.
From where I sit it seems that the media are the people that need educating.
I've seen too many articles like this one reinforcing the same ill-informed opinions which only help lazy developers who are only interested in selling products and not supporting their users with upgrades and fixes.
Once the media finally realise that the security problems we face every day are mainly cause by lazyness or rushed product cycles then maybe we'll stop having to read this kind of crap
My point is that the crime isn't going to go away. We have to take it as a given on the Internet.
Your grandmother's village is somewhat like a non-Internet connected machine. Perfect for some people and situations, and almost completely safe. But the public Internet is like the big city: you'd better have good locks.
So what about companies that want secure computers? They need to root and sniff their own machines rather than hire someone who actually knows security? Kind of silly to me...
Witty quotes suck.
I for one think full disclosure is the only way holes will be fixed and systems secured. Where does he think he will get new attack sigs from?
Report your new vulnerabilities to NFR only so they can keep it a secret and roll it into the next signature file version? Hmm strike NFR off my IDS solution list.
Like those guys at NFR aren't all subscribed to bugtraq.
Microsoft aggravates my tourettes syndrome.
I agree with Marcus's contention that not every person who exposes security holes do so to help companies fix their software. (And creating tools to exploit these holes definitely don't help, much like making lock-picks don't help improve locking mechanisms.)
But who's fault are these holes in the first place? These holes tend to be serious bugs that need immediate attention to be fixed. True, having script kiddies exploit these holes left and right is less than desireable, but they should provide even more incentive to getting these holes patched.
Is Marcus arguing security holes shouldn't be announced to the general public because software companies have more important things to do than to fix bugs?
George Lee
Consider the source. Mr. Ranum is just trying to build his company's market. That is why he wants to whip up hysteria (e.g. "weapons dealers" ... "terrorism" ...), and that is why he advocates keeping vulnerabilities secret. Disclosed vulnerabilities get fixed, and we know they have been fixed. Mr. Ranum doesn't want that; he wants us to be ignorant and afraid.
Be honest, CmdrTaco, you just posted this to piss us all off, didn't you? :)
Right. I would like to sue the Acme Crowbar Corp., because a burglar used one of their illicit tools to open my front door. They aided and abetted a criminal. The tool was /designed/ for forcing the opening of crevasses, and used to harm my property.
Weapons of Mass Analysis
The guy quoted in this story seems to advocate against full disclosure. Malda seems to think this implies the absense of any disclosure.
Can't there be a middle ground? Can't we disclose enough information to accurately describe the problem, workarounds and/or fixes (preferably from the vendor itself, in the case of vulnerabilities not yet "in the wild") without publishing script-kiddie-compatible exploits that run right out of the box?
If your system is B1-compliant, who CARES if a script-kiddie has a PERL script capable of stress-testing a Linux box?
If you're worried that the locks can't tell the difference between a key and a can of coke, then sure, obscurity is effective. But if you KNOW that your systems have bullet-proof authentication and that holes simply don't exist, then WHO CARES WHO KNOWS WHAT????
The fact is, a lot of "armchair experts" -don't- bother giving their code even a cursary audit, never mind anything stringent. If it compiles, run it and worry about the holes when Swiss Cheese companies start suing.
Even if there ARE holes, though, the environment SHOULD ensure that everything is in water-tight, sealed compartments. You mean, it doesn't? Then stop whinging about skript-kiddies and start coding! Side-effects, over-runs, undocumented pathways, etc, should NEVER be capable of accessing data or code that is not explicitly associated with that application.
Last, but not least, does this "expert" think that OB1 is any less secure for being available? Or is it MORE secure, for being checkable and usable by people other than SGI?
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
- They are too tempting for script kiddies who want to show off for their friends,
- It is too hard to get the word and patches out to all users quickly enough even if a fix is produced quickly.
This puts everyone using the software at a disadvantage and causes alot of wasted time and energy defending yourself from script kiddies' latest toys.Security holes should be published though because it is the only way to prompt vendors and software authors to fix the holes. It also alerts users to potential security risks so that they can choose another product, defend themselves some other way, or look for the patch.
So the tools to exploit holes should probably only be distributed to a select few who are capable of fixing the problem and the problem should be published to prompt them to do something about it and to inform the public. Unfortunately, many people producing these tools are often doing it for their own egos.
I find it astonishing that Marcus Ranum spews bile out of one of his faces on the "grey hat" hackers and those who expose security holes, yet speaks words of glowing praise out of the other one for a book like "Hacking Exposed" which, of course, gives anyone who cares to read it step-by-step instructions and pointers to all the evil "sploits" Ranum was ranting about.
I gotta get a tight tension on...
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.
--
This is not my sandwich.
The code for implementing an exploit, is entirely different from the code required for fixing the problem.
For example, or Grey Hat finds a buffer overrun in a server app, writes his 20-line exploit example, and posts to BugTraq. It takes Joe Developer, cursing and spitting the whole way, several hundred lines, carefully placed at every possible source of external data, and at possible string transformations, because the vunerability isn't in his code.. It's in the strings library that his Company has standardized on.
Make no mistake, I believe in openly posting bugs and issues, but don't confuse exploit code with resolution code.
Weapons of Mass Analysis
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.
Politics, Culture, Food?
Just like everything else one can imagine, full disclosure has it's bad points. The trick is to choose the set of bad points that creates the least amount of real-world trouble.
Personally, I'd rather know what the bugs are, know that someone is doing something about them, and actually have the ability to hold the vendor accountable. That's one of the reasons companies love buying from big vendors (IBM, Sun, etc): Accountability. You can't hold IBM accountable for a bug you don't know exists.. Until someone rm -rf's you and leaves a humorous note as to how they did it, that is..
--
Lack of full disclosure means the security holes live much longer and propagate until they're very wide spread. Then some 5kr1p7 k1dd13 stumbles on an exploit and suddenly the bulk of the world's computer users is vulnerable.
Full disclosure may reveal vulnerabilities earlier. But that's the time to plug them and it gets done much more quickly.
Dick lives in a house. Dick's house is in a neighborhood. Dick's neighbors live in the neighborhood. All the houses in Dick's neighborhood have doormats in their yards. Some of Dick's neighbors keep their extra house keys under their doormat. Dick finds this out and is very concerned that someone could find the keys and unlock the houses. Dick puts up signs all over the neighborhood. The signs say that some people have been keeping their keys under their doormats. Dick says this is bad. Dick lists all the neighbors who he knows keep their keys under their doormats.
And I, on the other hand, feel that financial loss shouldn't even be CONSIDERED - Human harm (both physical and psychological) should be the first AND final consideration. What's best for PEOPLE - not best for faceless corporate entities, governments, or machines.
-Hentai [in vita non pacem est]
So, someone finds an exploit in a program that I am using and publicizes this fact over the Internet. Now, instead of one person being privy to this information (the discoverer), or twenty persons (the simultaneous serendipitious co-discoverers), 50 MILLION cretins now have the power to utilize this exploit. Let's do the arithmetic: do I want 20 potential attackers, or 50 MILLION? Hello? Not a hard decision, is it? Further, why do these noble Hacker Knights find it necessary to provide explicit instructions and TOOLS so that any moron can utilize their exploit?
I'll agree that, if I were a public-minded hacker who had selflessly invested hundreds of hours of my time uncovering a dangerous exploit, and, after reporting it to the vendor, no action was taken after a reasonable interval, I might be a bit miffed that the vendor was so ungrateful. I would then certainly publicize the exploit, but WITHOUT GIVING DETAILED INSTRUCTIONS!
"Grey hat" hackers don't exist. They are publishing the results of their hacking for personal gain, whether that gain be fame or monetary.
Fuck 'em all with a broomstick.
Neopets - the best free game on the Int
And the vendor is still sitting there with its fingers in its ears up to the elbows.
There is something to be said for publishing the existence of the hack without detailed instructions. That should be the second step, after contacting the vendor directly.
But there's still far too many vendors who won't bestir themselves even at that step. Would you rather have 50 million hackers next week with no patch to come for months, or 50 million hackers AND a patch tomorrow?
--
--
Do I look like I speak for my employer?
Loyal
I aim to misbehave.
what makes he thinks that with 'white hats' out of the picture, there are going to be less script kiddies? The system hacking activity will just shift underground and proper authorities will have tougher time figuring out how they did it and customers will be lulled my marketers into false sense of security. I guess it is easier to blame on something you can see rather than what you can't.
And there I go misusing the word hacker. I know better. :p I should take a break.
--
--
Do I look like I speak for my employer?
You're right. Nobody actually reads the source code. Ever. Somebody writes it, then it's never read again, by anybody else.
Certainly aspiring young software engineers would never read the code to find out just exactly how an OS works. Certainly I never did that. And I'm also quite positive that I never read the source to a driver because I needed to find out why our custom version of the same network card wasn't working. Nor did I read the source to various system utilities when they didn't behave as expected.
In conclusion, open source is doomed to a buggy abyss, only a commercial closed source release system, with a QA department can provide us with good, quality software, like Windows ME.
----------------------------
In theory, it would be great if only those that "deserve" to know about the problem are informed. But who decides? As a sysadmin, I certainly want to know. It could be argued that sysadmins *need* to know, with as much detail as possible. And once you tell all the sysadmins, well, you are basically telling the script kiddies. It is a prctical impossiblity to keep a secret among so many. It is extremely doubtfull than even if the select group included only, say, NFR, ISS and Cisco, the secret would remain one. And someone with a very good fix may be outside the appointed elite (remember having to patch htr again and again?). Aside from the fact that nothing is stopping a grey/black hat from discovering the hole independently. Heck, they could have known long before we did!
;)
-
As for security through obscurity. It is *ALWAYS* a bad idea to rely for your security only on a secret. It is always a good idea to divulge as little as possible about your security measures. When we say that security through obscurity is bad, we don't necessarily mean that you should tell the world the exact implementation of encryption you use. We mean that you better be using real encryption and not a xor with a magic constant. (Apologies to we for including them
-----------------------------------------------
This is a work of fiction. All the characters, events and opinions posted are fictional, and any resemblance to real people, incidents or opinions is purely coincidental
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
-----
Go ahead, blame me... I voted for Nader!
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.
Compu terWorld also covered this story, with a little different slant than Excite's coverage.
These guys are saying, we can't be expected to write decent software anymore, this is the MS age of crappy software and security. Users love it, they buy our stuff non-stop, and all these stupid people trying to prove how really, really bad our software is are just mean. Screw the users, just pay us.
-- Keith Moore
This sig is the express property of someone.
Why did Microsoft ever have a scripting facility with no security checks? Why do products still have buffer-overflow issues? Sloppy design and coding. Until the bar is raised for the production of software (ala OpenBSD), this will continue.
The REAL problem is that people have no understanding of the origin of these problems. Once it is common knowledge that sloppiness in design is responsible for the Love Bug virus and web-site hacks, people will demand better software and be willing to trade some convenience for security. Current design holes are the equivalent of buttons all over a car which will unlock the doors, un-latch the steering column and start the engine. Nobody would tolerate a car that is so open to theft, and nobody will tolerate software that is equally bad (as so much software is today) once the public is sophisticated enough to know the difference.
--
Time is Nature's way of keeping everything from happening at once... the bitch.
I don't think the analogy fits too well. It's more like we're tenants and the software houses are the supers. Suppose somebody finds a way the locks in the building can be easily defeated. Now they have a few options:
1. not telling anyone
2. telling just the super
3. telling the super and the tenants
4. telling everyone
Obviously (1) won't get anything fixed. (2) is a bit curious, as it relies on the fortitude of the supers. (3) or (4) would result in some action, if not on the part of the super, then possibly by the tenants and maybe even legal action against the super if nothing is done.
But this analogy still isn't dead on. Option (3) would be very difficult to achieve with any publicly consumed software, thus (4) is the only feasible way to guarantee that the people who need the information (consumers) gets it.
The proliferation of security holes that are more often than not the result of buggy coding rather than actual security shortcomings is the true problem. Encryption routines exist that can not feasably be broken, but still people use simple XOR and create trust models that open themselves up to attack
True, returning to the above analogy, in some case the people reporting that the "house is unlocked" are in fact the "police" of the given situation, and that is contemptable, but double agents have existed literally since the beginning of recorded history, and so this is not some new aberration of the computer age.
Linux is a perfect example of how full-disclosure can create a very secure set of programs. Often security holes will be openly discussed and fixed as soon as possible, instead of M$ (and the numerous other guilty parties) who try and deny accountability and blame the user (or in the case of ILOVEYOU their competitors).
While it is also true that since the beginning of recorded history people have practiced obfuscation (the king moving from castle to castle secretly) it is never the complete solution, because you can never prevent a hole from being discovered, no matter how much concealment there is. The best approach is to try and write code without holes, and fix them when the come up. True people write progs for the scrip kiddies as soon as the realize the hole is there, but by the time the script kiddies get the proggies, why the hole still there?
sell your certainty and buy bewilderment
You already know your lock is broken. Fix it. EOC
We're talking about companies who store your data, your website. If you want to break into a site on geocities, you have to break into geocities first. But then you've just broken into every geocities site.
If a company chooses to ignore security, who do you turn to? Daily gov't crash tests? Yeah right.
Your door and the classic case we're talking about are completely different. Trust me on this one: You do not know if the lock is broken when companies are the topic.
The message on the other side of this sig is false.
"Full disclosure is creating armies and armies of script kiddies," said Ranum, who called the creators of hacking tools "weapons dealers" who aren't really concerned with security.
The alternative to full disclosure is that security holes that exist will never be patched. MSFT has sat on security holes for months until pissed off hackers wrote exploits to show the holes in their software (e.g. Bubbleboy.). I personally have turned in Hotmail security holes that have never been fixed but would if I wrote an attention grabbing exploit.
I sympathize with security people who have to deal with 5cR1p7 k1DD3z who get their information from Bugtraq but even worse would be never having these security holes broadcast and instead having networks being brought down for unknown reasons. To my reckoning it is far better for both the good and bad guys to have information about holes instead of only the bad guys.
PS: The crack about security people going to security conferences during the day and writing cracking tools for 5cR1p7 k1DD3z is worrying though.
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.
NFR salespeople, if you're reading this:
This is why I don't return your phone calls.
--
Having the sources to exploits makes it easier for administrators and system engineers to measure the degree of risk posed by a particular exploit, and the extent to which a work-around has succeeded.
Truth to tell, there is no other way of telling for sure (particularly for DoS hacks) whether you have reasonably addressed a particular problem. (It is not, of course, sufficient to do such testing, but it is often quite helpful if not necessary).
yeah, i thought about that too....digital signatures?
Admit nothing, deny everything and make counter-accusations.
security, which means securing the system against a determined and
skilled attacker. You have to secure against not just all known
attacks, but must also apply the best practice to minimise the
vulnerability from unforseen attacks. The other kind is basic
security, which protects against the `random intruder'. This means
investing abit of effort in measures that protect your system from the
most egregious holes.
Security through obscurity is bad for real security, but it is
probably good for basic security, since if exploits aren't published
only the experts know about them. Obscurity isn't a real defence, but
it has a kind of sociological advantage of increasing the amount of
work involved in breaking your site.
The problem with these arguments is that they assume two things:
1) Your goals and my goals are the same (or even compatible)
2) My short-term goals and my long-term goals are the same (or even compatible)
Security through obscurity IS good--for vendors, short-term. It is also somewhat good for customers, short-term. A bug no one knows about is a bug that no one is exploiting.
But it also means that a cracker can exploit it tomorrow. That's why for customers LONG-TERM non-obscurity is best. And that's why companies who pay attention to the long-term use non-obscurity.
--
Give us our karma back! Punish Karma Whores through meta-mod!
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
>(5) So, I **MUST** release the code showing what I did so others who do know the kernel well can fix it.
Here's the crux of the matter: release it to whom? Release it to people who know the kernel well, who have the ability and inclination to fix the problem? Or release it to people who don't know squat about the kernel, who are more likely to contribute to the appearance of a canned exploit on rootshell than to a fix?
Slashdot - News for Herds. Stuff that Splatters.
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.
For instance:
(1) I write code that makes many calls to the linux kernel.
(2) I am unfamiliar with the intricacies of the kernel.
(3) I find a call with some messed up parameters that inadvertently gets me root access.
(4) I do not know how to fix it in the kernel, but other people do. Maybe I just don't have time to spend fixing the kernel.
(5) So, I **MUST** release the code showing what I did so others who do know the kernel well can fix it.
And vague descriptions by me of what I did only slows the creation of a patch because I may articulate incorrectly or leave out vital info about stuff I'm unfamiliar with. The source code is always true.
Security through complete obscurity may have it's merits (ie: you don't know what kind of box I'm running, where it is, or what it does, and you can't really find out).
Keeping as much as possible secret about something has it's merits, but only if it's done in totality.
If it's network software we're talking about, that's publicly sold, this doesn't hold up, as the software is there for tons of people to hack away at and find vulnerabilities, source or not.
If it's your own IP stack, on your own hardware, and nobody outside of a trusted group will *ever* see the code, obscurity may give you some cover, as nobody can experiment on you.
Aw, put a sock in it!
The message on the other side of this sig is false.
As a homeowner with a Brand-X lock, you feel secure. The Brand-X lock has the most complicated key you have ever seen, and the lock is hardened steel with dozens of anti-tamper function. You feel really secure.
:-)
Brand-X locks have a defect which means they can be opened by anyone inserting a screwdriver and turning it. The manufacturer knows this, but doesn't say anything. This is security through obscurity.
Thieves (script kiddies) have discovered through experimentation the screwdriver trick. They occasionally wander down your street, looking for Brand-X locks.
If the manufacturer of Brand-X locks were responsible, they would put out a recall notice and replace all the defective locks. But they aren't, so thousands of homes are broken into by thieves who have learned this exploit. Many homeowners learn of the defect from the police after the fact.
Once a news report is published showing the fault with Brand-X, many of the consumers clamor for replacements. Eventually the manufacturer gives in and provides new locks to those who ask for them, putting a positive spin on the whole sordid affair. Draw your own parallels with this action
the AC
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on
Well, I think the best security would be one that combines "obscurity" with other measures.
Security through obscurity alone is not good security at all, but obscurity as one layer of a security system is not a bad thing.
Of course, then you are relying on everyone else to be forthcoming with their own security issues; you study and implement, while you selfishly contribute nothing in order to maintain your own obscurity.
Selfish, but it would be hard to deny that this would provide better security than (what's the opposite of obscurity? Clarity? Brazen openness?) non-obscurity.
Another approach to obscurity is distraction and obfuscation - present an obvious target to distract attention from the important stuff. Still not good on its own, but important as part of a whole security scheme.
-------
-------
"It was people! People soiled our green!"
IMO, this should be the standard response.
Where is his proof in saying that disclosing bugs does not make for better security? I/We have a lot of proof to the contrary. OpenBSD. Linux (yes, I know most *nix types scoff at Linux "security", but compare it to NT/2000 in a corporate environment, with all those Outlook holes, etc., etc. ad infinitum). Sendmail. Even WuFTP for chrissake. I mean it has had bugs in the past, hell I even got root compromised because I fell asleep for one of them, but the problems get FIXED. That way, a SysAdmin who's on top of things can actually keep his system *secure*. Talk to some NT admins sometime, and hear them bitch about being forced to run Outlook on all their systems, even though tere are *known* exploits with *serious* depth. I would *much* prefer to live in a world, and run a network in a world, that has the bugs exploited, posted and fixed. And that's all I have to say about that.
"He's more machine now than man, twisted and evil."
I'll give you a box of grits for the 31 karma account. For the 33 karma account, I'll heat them up. For the 52 karma, I'll pour them down your pants. And for the 76 karma I'll do it dressed as Natalie Portman. Deal?
There is an interesting issue of the balance of power in the grey/black hat community. If the exploits are published, then the real crackers (who actually discover them and write exploits) are not much more powerful than the script kiddies: they understand the tools much better and they have them earlier, but it's the same tools after all.
Now, if the exploits were not published, then script kiddies would be left high and dry (well, as soon as the net patches the holes known today -- might take around five years, I think) and the real crackers would be in a much better position. Not only would they have less competition, their ways of breaking in would be generally unknown and thus generally unpatched.
I am quite sure that Marcus Ranum is not a black-hat guy bent on eliminating competition, but the real consequences of this suggestion would be the lessening of the script kiddie power, but the increase of the "real cracker" power.
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
When I released shellcode for Digital Unix, I did so after having given Compaq months to fix their problems. After releasing it I was contacted by people who had developed the same exploits over a year previously and disclosed them to Digital/Compaq and they had done nothing. By releasing actual exploits to the wilds they actually got their shit together and fixed the bugs and started shipping their O/S with root having a non-exec stack by default. That's a net security benefit (non-exec stacks on alpha architecture are very tough to crack) caused by public disclosure of an exploit.
I don't mean this to be a media rant, but they can't really keep up with every development, and even if they could, people's attention spans would dry up after seeing so many warnings and only one or two superpublic exploits. So even if there were a medium for communicating possible holes to average people, they wouldn't care anyway.
Public disclosure: damned if you do, damned if you don't
I don't think that by long term, any closed source product has proved to be more vulnerable than their open counterparts. Just compare the amount
of security holes in commercial unixen to the free ones. Well, maybe OSS ftp servers have had an bad record, but I take is as the exception that confirms the rule...
Anyway, by obscuring your network, you can win. Ping/tracreoute from outside your own net? who needs them after your network has been built? Apart from participating in netcraft, who needs to know your webservers brand, version, and even the OS?
a: Kiddies scanning for exploits.
If you can't be found, you can't be attacked.
Only drawback is, that if your network is down, it will take more time to find out why.
signatures pending - ansa@kos.to - (dont mail there)
No! ofcourse not! You see: even if a vendor of software, let's take Sun or Microsoft, checks bugtraq at the same time as a legion of scriptmorons do, they can't avoid a possible hell on earth when the bugtraq posting comes with a plain tool to exploit the security hole right away!
There is simply no _TIME_ for the vendor (or linux distributor) to patch. It then also takes a while before the majority of products around the globe are updated, so during that time, the scriptkiddie or similar individual has a weapon at hand, and only has to press a button to exploit the bug.
This discussion should be focussed on the area between: TOTAL nondisclosure of ANY securityhole whatsoever vs TOTAL disclosure of ALL securityholes and every securityhole should come with FULL exploit tools and exploit how-to's.
IMHO too many people are focussed on one of the ends of the possible solution area. Don't. both edges are not helpful.
--
Never underestimate the relief of true separation of Religion and State.
'Script kiddies' is intended to create a negative image. It's supposed to denote an immature person who relies on scripts (other people's work) to cause trouble. It's meant to be a derogatory term that hackers use to refer to wanna-be poseurs. The motor-head community has a parallel term, 'rice boy'.
Your argument holds completely true for the term 'hacker', but defending 'script kiddie' or aspiring to wear that label with some sort of pride, is selling yourself short.
While 'script kiddie' implies an adolescent, it doesn't work the other way. A computer-savvy adolescent is not necessarily a 'script kiddie', though (s)he is most certainly a geek, and may be a capable hacker.
Are your teachers really so insecure about their lack of computer knowledge that they would right away label you as a miscreant, simply because you know more about computers than they do?
-- What you do today will cost you a day of your life.
You got the men with hats, and their 80's hit Safety Dance (yeah, it's going through your head now, isn't it).
And then you got the man in the yellow hat, who is only dangerous to little curious monkeys.
george
Marcus is way too smart (and opinionated on the subject) to have failed to distinguish between white, black and grey-hat crackers, so I suspect the reporter has missed something.
I speculate he said that white hats are good, black hats are bad, and grey hats are making a big mistake, contributing lots of efforts that are picked up by script kiddies, who are black hats, and used to attack innocent bystanders.
Anyone considered asking him? (;-))
davecb@spamcop.net
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
What annoys me is how so many daemons are far too keen to show off exactly what they are. My web server does not need to reveal that it is Megatronic-httpd V1.03.23b; although it will do because Megatron Corp wants the server to appear highly in netcraft surveys.
When I am university I get a lot of probes on my machine, these are almost always site wide probes. Script kiddies keep databases of IP's and what daemons they are running. This means that as soon as an exploit is found they can immediately go to a load of hosts they know about. I check security bulletins but not twice a day like a lot of script kiddies will.
Of course with open software it is easier to remove any version reporting. I'm not arguing against open software. However, rubbishing obscurity of all kinds is foolish. Sometimes it will buy you just enough time to keep ahead of the kiddies.
What utter fucking nonsense. The problem with security holes is: a)too many people know about them, b)they would go away if we just all pretended they didn't exist and c)the fault lies completely with evil little hackers and not with the people who wrote and can fix the problem.
Hey pundit-guy where do you think these problems get exposed from? From the vendor? Or from the results of dedicated efforts to break something.
Does anyone honestly believe that any commercial vendor would fix something no one knew about? Do you think any IT empty suit would tell their galley slaves to row faster if that person's boss could never find out what problems they are exposed to?
What do we call this? The rhythm method for IT security, that's what.
How's an admin s'posed to find out he's running broken code, if the one who finds it doesn't tell anybody? It's the same concept as the MAPS Realtime Blackhole List, and the list of open mail relays--refuse enough mail from an open mail server, and the mailserver admin will have to fix his relay. Make public the fact that version x of whatever software package has a security hole, and admins will either fix it or risk losing data. Plus, OTHER admins will have the opportunity to seek solutions as well...
"I say consider this day seized!" -Hobbes
"Tomorrow we'll seize the day and throttle it!" -Calvin