Slashdot Mirror
Hacker Leaks Unreleased CERT Reports
Call Me Black Cloud writes "A hacker calling himself "Hack4Life" swiped 3 unpublished vulnerability reports from a company working with CERT and posted them to the Full Disclosure mailing list. A couple of days later, he did it again (while promising weekly leaks). Wired also has a story, including a link to one of the postings."
Its a little too ironic if he's using the leaks in the reports he steals....
If you enjoy Bugtraq and can put up with the occasional flame war ... FD is an awesome list.
FD Charter
KARMA TAG! You're it.
I drink too much coffee. I leak several times per day.
How to Download YouTube Videos
What is interesting to note, is that this, or these, as it may be hackers are /releasing/ the truth.
Not defacing web sites, hacking student DB's, etc.
Is truth the new hack of the future?
The connotation of the word has changed, deal with it, move on. You lost this war years ago. If you don't like what it now means to everyone but you and a few others, then don't choose it as your label.
Simply put, if the masses see "hackers" as evil criminals then that's what "hackers" are. Language is determined by the masses, not by a small minority who get to determine what's PC or right.
scott
I've never liked the fact that CERT was more or less an exclusive security club. It's obvious that hackers monitor the mailing list and know the vulnerablities before majority of everyone else in the world.
CERT should instead, stick with helping behind the scenes coordination between security agencies like eEye and software companies; and should stop publishing unfixed problems to a CERT's underground mailing list.
What concerns me is that one of the vlunerability reports released by this guy wasnt schedualed to be released until June... JUNE??? What the hell are they going to wait till June for. Cant the vendor get their act together before then? This is why we need bugtraq so bad.. IMHO they should get 3 or 4 weeks max to fix the problem otherwise it gets released. If there is even a hint its being exploited on the net it should be released immediatly, fix or no fix.
Malice95
I was somewhat torn on the issue until I read "I'm going to release these at 7pm on Friday, so that sysadmins don't know about this and can't do anything about this til Monday morning" (paraphrased).
Any inkling of having me agree with posting these advisories just went out the window with this one. He's not trying to help anyone by divulging these, except for maybe script kiddies and crackers. With such a statement it's obvious he's not trying to help vendors release a quicker fix.
It's better to burn out than to fade away
Maybe so, but a good kick in the ass of the CERT and the vendors can help speed things up. When an advisory has been in the pipe for a while and is only scheduled to be released in 3-4 months, clearly vendors are a bit lenient in fixing their bugs. Next thing you know the CERT cycle will be 12 to 18 months...
Finally, let's use a non-digital example. If (e.g.) Consumer Reports found a flaw in a popular child car seat that could cause severe injury to a child, which path would you prefer they take:
- Notify the manufacturer, then wait for said manufacturer to discover a fix and write a press release.
- Loudly notify the entire world so that parents can reduce the risk themselves.
In the above case, the only reason to delay is to protect the manufacturer, so the analogy isn't perfect. Home burglar alarms would be a better analogy, but less vivid.For many people charged with security, this is an easy question: they want all possible information on vulnerabilities the second that someone discovers them. They can shut off services, craft firewall rules, compile in patches, write their own damn patches. The worst-case scenario for them is that their systems are afflicted with a vulnerability that anyone else but them knows about.
Besides, here's the elephant in the living room that no one wants to address: if one person can somehow acquire this information and post it to a public list, another person can use the information for ill gain. One of these vulnerabilities wasn't due to be announced 'til June?? That's a long fucking time for (e.g.) your bank's online transaction processor to be vulnerable.
Disclose early; disclose often. Anything else multiplies the risk for the people who can least afford it.
This isn't as much "normalization" as it is "don't take so many drugs when you're designing tables."
If everyone switches to BSD then most of the vulnerabilities found will be for BSD. No OS is flawless, not OpenBSD nor any other - OpenBSD gets more attention than the other BSDs as far as security is concerned in all probability because of their security stance, but there's still a hojillion (I use that term strictly in the technical sense) bugs in there.
That's not to deride Theo & crew's accomplishments - they've done amazing work, look at how few bugs are found in OpenSSH relative to how incredibly widespread it is - but it is practically impossible to write perfectly secure code that operates at anything like a reasonable speed for the x86.
How do you define when a vulnerability is fixed, at least for the purpose of determining when to go public with it? Consider a vulnerability in some shared and widely used and distributed library such as OpenSSL or Zlib. Potentially you could say it is fixed as soon as there is a source patch. But that doesn't really make it universally available. Armed with the patch, the vulnerability may well become obvious, yet most systems which are installed and maintained in binary code remain vulnerable. Should things wait until the distributions package the fix? How many have to wait for the others?
And what if the same vulnerability exists in more than one implementation because of things like code re-use, or a flaw in a protocol that can be dealt with in the code anyway? Suppose OpenBSD fixes theirs in 2 hours and NetBSD fixes theirs in 5 hours and FreeBSD fixes theirs in 9 hours and Slackware fixes theirs in 15 hours and Debian fixes theirs in 24 hours and SuSE fixes theirs in 36 hours and Redhat fixes theirs in 60 hours and Microsoft Windows fixes theirs in 10 days (hypothetical times chosen arbitrarily)? Would it be OK for OpenBSD to go ahead and blast their security mailing list with the fix when it's done? Or should everyone have to wait until the stragglers get their act together?
IMHO, vulnerabilities should be released as soon as the first vendor has a fix, or after some fixed determinate time to ensure they don't all get together to hide the problem (not that all of them would, but certain vulnerabilities may only affect a small subset of them, or even just one). Yes, that leaves the systems "supported" by the stragglers unprotected. But that should also help leverage market pressure to fixing things faster, and designing to avoid the as well.
now we need to go OSS in diesel cars
Finally, let's use a non-digital example. If (e.g.) Consumer Reports found a flaw in a popular child car seat that could cause severe injury to a child, which path would you prefer they take:
What usually happens in this scenario is that parents remove the childs seats in blind panic and as a result 10x more kids are killed by seatbelts and not being in carseats than would have been killed by the carseats.
Lucky we removed those car seats isn't it?
Alex