Slashdot Mirror
CERT And Vulnerability Disclosure
Carnage4Life writes "In a radical departure from it's previous stance of security through obscurity, the Computer Emergency Response Team, CERT, has stated that it will fully disclose all vulnerabilities in software that come to it's notice 45 days after the fact whether or not companies have provided a fix. The change of policy can be found at the CERT site and there is also a story on C|net.
The change is not a complete embrace of full disclosure because CERT will not release exploits as some other software security watchdogs do."
While all of you are discussing the ideological and legal aspects of this, I think I would like to address the practical side.
Very few novice Redhat 6 users, myself included, actively monitor the security problems addressed at bugtraq or securityfocus, out of ignorance or lack of time. However, the Internet is crawling with 5kr1p+ k1dd135 who do, and they have preyed on our system. I do not appreciate the abstract, idealistic attitude of this community, the good-ol-boy mentality that if you aren't an expert administrator, you ought to be hacked by 14 year old malcontents. They used that goddamn wu_ftpd exploit on us and we had to reformat and waste another freaking day reinstalling and upgrading the only OS I've ever personally seen hacked.
Now RedHat wasn't the only distro affected by this exploit; this is truly an open-source security problem. Consumers will not latch onto Linux if it's this hard to keep secure. There are several items your community needs to address:
You might not care if all the "dumb" users go away, but you know what? Then your OS won't win, you will always be stuck in nerd obscurity, and MacOSX will be the #1 unix in the world.
a prophet on the burning shore
You have no need for a coded exploit - if you can't write it yourself, what chance do you have to understand it? And if you don't understand it, what possible LEGITIMATE use do you have for it?
Testing whether or not your particular setup is vulnerable or not sounds like a pretty "LEGITIMATE" use of an exploit to me. I shouldn't have to understand every possible security problem in depth and write my own test exploit just to determine whether I'm vulnerable.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Full disclosure is the right way to go... WHEN handled sensibly. You have no need for a coded exploit - if you can't write it yourself, what chance do you have to understand it? And if you don't understand it, what possible LEGITIMATE use do you have for it?
.. :-)
I as an admin have legitimate use for it. I'm able to run the exploit against my box, to check if I'm vulnerable. If its a proper description of the vulnerability in addition,i'll be able to check if the flaw is there at all in my version of the software.
Exploits is an easy was to check if you're vulnerable and needs a patch. Its helluva lot easier than to check if you've got the updated libs, and if the program is updated, and versionchecking everything.
Of course, its not foolproof. You may be vulnerable even if the exploit doesn't work. But, if you run redhat, and the exploit is for redhat, then
Furthermore, you say that full disclosure is the way to go. And right afterwards, you say that exploits shouldn't be released. Sorry mac, its not full disclosure if you don't disclose everything. You seem to have misunderstood something.
For example, while MS didn't improve LanMan until l0pht released l0phtcrack, neither was anybody cracking it!
And how exaclty do you know that? When l0pht released the informatiom, security minded people were able to patch their systems, because they forced a fix to be made. If they had not publicised the information, you wouldn't know about it. You wouldn't know that you were vulnerable, and if you had a smartass cracker around, he could run circles around you without you understanding what the fsck were going on.
You seem like a troll, but are modded to 5.. I don't get it.
The number of people actually capable of discovering new holes AND who are shady enough to exploit them is so tiny that the odds are high an average user will never be affected by them. Most of these people spend all their time coding up "exploits" for skript kiddies today anyway!
And how can you be so certain about this? You really can't. What is unknown is unknown. You are doing nothing but theorizing right now.
Btw, as far as I know, slashdot has been cracked once without anyone having any idea on how it was cracked. Furthermore, rootshell.com was cracked about 1-2 years ago. I don't think they've discovered how yet. So, you are saying that the superhackers don't exist, even so, we see this kind of things.
Keep in mind that your enemies are the skript kiddiez, NOT the corporations or end users.
I seem to remember som corporations using more than a year in patching some holes. I think they are my enemies, not the scriptkiddies. And I've been cracked by scriptkiddies. If the tools weren't widely published and available, I would never've known what hit me. (maybe i wouldn't have been hit, but that i can't know).
--
"Rune Kristian Viken" - http://www.nwo.no - arca
Funny, I got an ILOVEYOU just a few days ago but
I guess they fixed it by now...
L0phtcrack wasn't the first program to crack lanman packets. It was the first that combined all the known ideas into one package easy enough for a scriptkiddie to use.
Publishing exploits also expands the knowlege base of how typical exploits work.
15 years ago most programers would not believe that you can write a program that overflows the buffer of a second program causing it to do something uninteded other than dumping core. Now people understand buffer overflows are a real issue but only because of the huge library of exploits.
But they don't.. even then. If someone gets owned they immediately blame the purpotrator (and rightly so) and usually have very little vengence left over for the software company. Most software consumers beleive that "hackers" or "crackers" or whatever you want to call them, make the bugs in software, not the software makers.
How we know is more important than what we know.
Also a decent software provider can't release a patch without THOROUGHLY testing it first.
M$ did that kind of stupidities many times as an example...
I don't see as the exploits are needed. Sure, they should release them to those responsible for fixing the software, but there's no need to release them to the general public.
I would have to agree with this. Further more, by publishing exploits to the general public, you are just giving script kiddies the tools to break into something. Why make it easier for them to break into machines. If they are gonna do it, at least make them code up the exploits themselves. And hey, who knows. That young kid who right now is wipping some exploit up might grow up and turn into a serious responsible kernel hacker.
So this isn't a "complete embrace of full disclosure" huh? What exactly do you want? Possibly CERT should crack the app or site for you and hand you the root password as proof?
Full disclosure is the right way to go... WHEN handled sensibly. You have no need for a coded exploit - if you can't write it yourself, what chance do you have to understand it? And if you don't understand it, what possible LEGITIMATE use do you have for it?
I am always irritated by people who make flip remarks like "security through obscurity is proven not to work", when the basis for their remarks is that some vendors didn't patch known vulnerabilities in the days when STO was more prevalent. In reality, the aim of information security is NOT to eliminate all security holes. The aim is to prevent legitimate users from service interruptions and abuses. It's not that difficult a distinction, guys. For example, while MS didn't improve LanMan until l0pht released l0phtcrack, neither was anybody cracking it! The theory of some full disclosure zealots is that if all vulnerabilities aren't released and coded up within 24 hours of discovery, some shadowy breed of "super hackers" out there will find it in time and exploit it. Guess what - these super hackers DON'T EXIST. The number of people actually capable of discovering new holes AND who are shady enough to exploit them is so tiny that the odds are high an average user will never be affected by them. Most of these people spend all their time coding up "exploits" for skript kiddies today anyway!
CERT has it right. Disclose the vulnerability to the vendor. Give them A LOT of time to fix it, and a lot of goodwill. Software companies can be slow on their feet - they can't address every problem that crops up in the 12 hours you give them until you announce "they haven't responded". But if the problem is not patched in that liberal amount of time (45 days seems enough to me) THEN feel free to shout from the rooftops and embarrass the suckers.
Keep in mind that your enemies are the skript kiddiez, NOT the corporations or end users. For some reason it is easy to lose sight of that fact in the world of infosec, where everybody believes they are unusually smart and the companies they correspond with unusually stubborn. I know - I work in that field and ego is a dangerous thing. Don't let it blind you to what should be your real goal - helping people improve their lives.
-konstant
Yes! We are all individuals! I'm not!
-konstant
Yes! We are all individuals! I'm not!
When I read "will fully disclose all vulnerabilities in software that come to it's notice 45 days after the fact whether or not companies have provided a fix", I took that to mean that they would never provide full disclosure before 45 days. Not true at all, they will provide dislosure within 45 days. Big difference. Also (pet peeve, but I wouldn't post if only for this), you spelled "its" wrong.
ok then your [sic] infringing on my copyright! Could you as [sic] me next time before STEALING my comments for your own?
Let me first say that, in general, I welcome this change to CERT policies. CERT announcements have become increasingly less relevant as the bugtraq list has grown and as the SecurityFocus team has added better tools for tracking and researching vulnerabilities. One interpretation of this change is that it represents a desperate cry for relevance by the CERT folx.
Here's the rub, though: there are some vulnerabilities that cannot be fixed in 45 days. 45 days is plenty to fix a buffer overflow in a single software package (or even a common overflow in a group of packages). It is not nearly enough to fix a protocol weakness.
An excellent example of this is the SYN Flooding attack perpetrated on PANIX in NYC years ago. Let's rewrite history and suppose that the attack was mailed to CERT first (and not used in public first). CERT then would mail the details of the attack to the security contacts of every operating system at the time (since the idea of SYN queue resource exhaustion was viable on every IP stack at the time). And then those vendors and maintainers would do what?
Well, fix it, of course, right? The problem is that the fix isn't obvious (it still isn't obvious, years after the attack). You can reduce the SYN queue and time things out, but then you can get in trouble with timing out connections from viable end-hosts. You can use Dan Bernstein's SYN cookies (although it took someone like Dan to come up with these--they are entirely inobvious to the average protocol stack maintainer).
The problem is that the TCP protocol didn't envisage the presence of an entry on the SYN queue (SYN received, SYN+ACK sent, waiting for SYN+ACK to connect) as a resource that needed to be managed carefully. As a result, there's no easy way, in the protocol, to avoid resource exhaustion for this correctly in all cases.
In situations like these, 45 days is woefully inadequate. It's not clear if a year is adequate. I like the idea of forcing vendors to respond promptly and get this stuff fixed. I worry about the trend of using the innocents as cannon fodder (as described by Marcus Ranum, whose homepage at http://www.clark.net/pub/mjr appears to have disappeared. anyone know where it is now?).
Anyway, just wanted to point out that this is not as simple as the shrill FULL DISCLOSURE!!!!! folx are making it out to be.
First off, the longest time to break something broken from the get-go award goes to CERT :)
But glad to see they fixed it, maybe it'll make CERT something more then amusing now. Eg: "You just got that fixed? I mean CERT will be releasing an advisory any day now!"
Second, for those who don't understand the role of exploits... I worked for a software house as a sysadmin/manager at one point. It took the IIS valnerability and the speed of a working exploit coming out on BUGTRAQ to prove to our head developer that he needed to check for buffer overflows in code, as he previously felt that creating an exploit would be impossibly hard.
Once again, thanks CERT!
----
Remove the rocks from my head to send email
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
1) CERT is way behind anybody else
They issued an advisory about wu-ftpd and rpc.statd in July or August when exploits, and proof of concepts, were on bugtraq in late May.
2) CERT has turned into a laughing stock.
The funniest thing I think I've seen in a long time is Jamie Rishaw's mock advisory about the Sony Aibo. This is just a slap in the face of CERT.
I'm not mocking the concept... an entity such as CERT serves a very big purpose. Being associated with the SEI one would think a much more active one. However since white hats are just as skilled as the black hats it doesn't take somebody at the SEI to write an exploit. By the time they do, somebody has already posted it to bugtraq or it's already out in the wild.
Just my $.02.
I mean SecurityFocus/BugTraq has been doing full disclosure forever. Why didn't CERT start sooner? And if the k1dd13s want exploits they can get them from SecurityFocus or Packetstorm or something.
Sometimes you by Force overwhelmed are.
They've set up a 45-days after the fact disclosure policy, but they also put a bunch of loopholes in there allowing for later (or earlier) disclosure based on "negotiations" with the affected vendor and also the severity and sensitivity of the hole. So essentially what it says is "we'll disclose holes 45 days after they are reported, unless anyone gives a good reason why not, where "good reason" is solely up to our discretion." Not really very cut-and-dry, when you get down to it.
I don't see as the exploits are needed. Sure, they should release them to those responsible for fixing the software, but there's no need to release them to the general public (unless the general public is who is responsible for fixing the software, as in Linux).
Besides, it shouldn't take anyone more than a day or two to write an exploit, anyway.
With 45 days of secrecy, that gives companies a month and a half to put out a patch. This is probably way too long. 15 days to put out a patch is a bit more reasonable.
Of course, if you consider it as 15 days to put out a patch and 30 days for people to get it installed, then it isn't too bad.
Personally, I think it should be a two-tiered policy. 15 days of secrecy once the software vendor has been notified. Then, if a patch has been released that fixes the problem, an announcement of "unspecified security problem" with a reference to the patch should be released, followed by an explanation 30 days after people have had a chance to install the patch. If no patch is released, then the full details are released at the end of the initial 15 days.
Oh well, 45 days is still better than never--much better.
I think in general when bugs are first found, there should be a small window of time given to the developers to fix the bug. There is no need to publish a bug only to let every script kiddy out there crack your box. 45 days is pushing it way too far. Sure it's good that CERT is going to release more information, but I think that a more realistic set of time is three days. I think I read somewhere in which someone from OpenBSD stated that most security bugs can be fixed within an hour if the bug is known. Three days would be plenty of time. I know that some open-source zealots might think that all bugs should be reported immediately, but in truth this should only be the case when it is a true community project such as the linux kernel. Just because something is put under the GPL, does not mean that it doesn't have a main set of centralized developers.
There shouldn't be a blanket rule for security disclosure. If some thing is broken in Word fine post that up in 45 days if it not fixed by then the company might get a little bad press. But if there is something broken in a medical database (you notice that medical computers are always used to curry favor in these examples?) and they can't get it fixed in 45 days should the exploit be released anyway?
I say email the manufacturer, read what they have to say and if it seems like they are just sitting on their butts make the information public. But if doing so would endanger public safty maybe a different rule needs to be applied then "release after 45 days"
It's good that CERT are making strides in the right direction, as it will force tougher, faster action on the part of companies. Something that those companies have tried to avoid altogether through the new copyright acts, which made them exempt from haveing to make fixes.
The biggest question that remains, though -- is CERT, SecurityFocus, etc, legal, now? After all, publishing security alerts IS a form of review, unauthorised reviews are illegal, and I can hardly see names like Microsoft or Sun actively encouraging people to publish major security holes.
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)
The point is that with the practice of full disclosure, there's a real opportunity for upset customers and damage to reputation for the vendor who released buggy software..... I'd guess that software vendors would do even less testing and concentrate even less on security if they knew they were free from the risks associated with full disclosure.
If anything, what's needed is something that punishes software vendors for buggy code.
PJRC: Electronic Projects, 8051 Microcontroller Tools
I don't see why you say his manager sux. option 1: waste shitloads of money and blow an entire strategy which may make your company successful to fix a bug that may or may not effect you because you can't assess the situation properly or 2: ignore that "potential problem" and be cracked by some juvinile that will probably just install an eggdrop bot on your box but at worst could down your server for two days. Either way there is risk, you have to weigh the risks to make your decision.
How we know is more important than what we know.
Heh.. firewalls. Yer right. You know what "firewall" means to most companies? A wasted machine. "Can we use this box to run sendmail?" "Can we run apache on this machine?" "Why can't I ftp to the machine in the server room with all those EFTPOS terminals connected to it?" This is why companies started selling sealed boxes with "firewall" written on them, so people wouldn't think they were real machines. Unfortunately none of these companies can make a secure product (basing them on winnt doesn't help) and the tekniq for getting around firewalls is as long as your arm.
How we know is more important than what we know.
That's right folks. It should be illegal to post cracking tools and exploits. Why? Well because it's damaging to eCommerce because crackers will use it. Besides most of this stuff could be considered illegal because of reverse engineering which is indeed banned under the DMCA which, before you start bitching, is a morally just and much needed law to protect large corporations. So just shutup and eat at McDonald's and wear Nike shoes, and drink Coca-cola, and listen to Britney Spears, Nsync, or whatever other trendy music the RIAA wants you to listen to. Remeber, you don't have the right to choose what you do with your so called property or even your body so just live with it.
Knowing the detail of a vulnerability enables real risk assessment. How much of your systems are at risk? What's the value of what's at risk. It's impossible to figure this out without some notion of what the vulnerability is.
Security Admin: "We need to immediately upgrade all our servers to fix a serious security bug?"
Executive With Money: "What's our exposure if we don't?"
Security Admin: "I don't know. CERT just says to fix the bug."
Executive With Money: "And we are supposed to pull people off our Vitally Important Marketing Strategy Project to immediately fix a security problem, when we don't know what the problem is and what it costs us?"
If your children ever found out how lame you are, they'd murder you in your sleep
A lot of the "early" reports are motivated by the desire for credit for finding the bugs. It might seem petty and small minded, but so what? If that's your motivation for putting in useful work and publishing, who are we to criticize: go to it. If the companies/developers that have the security hole in their products enhance the glory for the discoverer, they might get more cooperation.
But early reports with exploits really light a fire under the fixers and create more awareness in the vicitms and potential victims, so in the long run it's a good thing, IMHO. But, MHO opinion doesn't matter: as I said, it's all about free speech.
This change is needed. There have been too many cases of vendors and users burying their heads in the sand about vulnerabilities. In practical terms, the threat usually exploits software bugs. not weaknesses of existing security mechanisms. The lack of vendor liability for errors and omissions in their software has meant that security-related bugs have been fixed only grudgingly. The UCITA has been a step backward; perhaps this will be a step forward.
CERT is no longer the "Computer Emergency Response Team."
According to their FAQ:
CERT" does not stand for anything. Rather, it is a registered service mark of Carnegie Mellon University.
Its history, however, is that the present CERT® Coordination Center grew from a small computer emergency response team formed at the SEI by the Defense
Advanced Research Projects Agency (DARPA) in 1988. The small team grew quickly and expanded its activities. As our work evolved, so did our name.
When you refer to us in writing, it's OK to refer to us as the CERT® Coordination Center or the CERT/CC. Although you should not expand "CERT" into an acronym, it's appropriate to note in your text that we were originally the computer emergency response team.
Why the crazy sig? I'm a security engineer. Crabs are the favorite food of octopi, and if you put one into a tank with an octopus, it's soon dinner. The method the octopus uses to catch the crab is very much like how a hacker usually breaks into a system--he looks for design flaws and uses social engineering, avoiding the security mechanisms themselves. So I am in the business of ...
Who needs CERT then? Just tell company directly.
Get the credit yourself. =)
but you forgot the first amendment makes 'unauthorised' reviews legal.
In the sense that you can't go to jail for it, yes. In the sense that you can't be sued into poverty, NO. That's the problem with the civil courts today, any big company can pretty much wipe you out at will unless your case can capture enough public attention (a big gamble vs. just shutting up).
First, if there's a hole in a product that has been found, the company has been notified, and nothing has been done about it for 45 days, I'm sure someone has and is using an exploit by then.
Second, by publishing the details, and saying "hey, you knew about this for 45 days; don't you think your customers should know?", you're encouraging software companies to get their act together.
If left to themselves, no, they won't fix bugs out of the goodness of their hearts. The only people this sort of thing affects are the consumers; big businesses have firewalls and probably use better, more expensive products internally, wherever possible.
I think it's pretty sad that it has to be this way, but that's the way it is. Taking a laissez-faire attitude to big software companies doesn't seem to work, because there is too much potential for abuse.
I also don't like the whole "unauthorized negative reviews aren't allowed" business. Who cares about freedom of speech, eh? We can have unauthorized biographies of Bill Gates, and not unauthorized reviews of Front Page. Whatever you say, guys. For example, I did a lot of benchmarking between DOS and Linux's DOSEmu; my findings at the time were that DOSEmu was about 3% slower in raw CPU than actual native DOS (testing using the DOS 32-bit BYTEMarks), but that defragging a native DOS partition was *much* faster under DOSEmu, due to Linux's cache subsystem. Those are the facts; why should they be censored just because someone else isn't happy about it?
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.