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.
Maybe someone that's upset with the way CERT is doing things...
or maybe someone joined CERT just so he/she could play uberhacker.
my pet machine
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?
This is both good and bad. Good, in the sense that more people will know about these vulnerabilities. Bad, in the sense that more people will know about these vulnerabilities. In my opinion, the only time security vulenrabilities should be released publicly is when they are fixed. Otherwise, teenage script kiddies worldwide will launch attacks on everything and everyone. It is unreasonable to expect all code to be completely secure, it is just flat out impossible. However, when new vulnerabilities are found, they should only be disclosed to those who have the capacity to fix them, and not to the public, whose only reaction will be panic. Comments?
I hate sigs.
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
Store the Windows vulnerabilities on a Windows server, Linux vulnerabilities on a Linux server, etc.
That might take the edge off some companies' complaints about vulnerabilities leaking out before the clock is up.
It's a bad thing. I mean, you can justify almost any crime that way ("oh, I was just testing your locks" or "oh, I was just testing police response in this area" or "oh, I was just testing human skin resistance to .38 caliber rounds").
Moreover, if their vendor doesn't patch their system quickly, how are they ever going to stop this guy if he always knows what's broken next?
Catch-22 isn't it!
That vulnerability is a simple buffer overflow. RedHat had a patch out for it in less than a day. This whole 'wait for the vendor to fix it' thing just results in lazy vendors.
And, as the army breakin shows, the 'bad' guys often have the information whether or not the 'good' guys even know it. There are many script kiddies out there, but there are a few really intelligent people who can do their own research, and won't bother telling CERT before they go and exploit the vulnerability.
Need a Python, C++, Unix, Linux develop
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.
Unfortuneately, the reason the information was leaked is because CERT charges people to get early access to security problems like this... So it could be *anyone* at any of the organizations that have legitimately (*cough*) gained access to this resource. Hell, it could be any one of those people's bored teenaged kid who snagged their dad's laptop when he brought it home for the weekend.
Sorry, but once you sell something there is no way to protect it as secret.
CERT has bought and paid for this. They've earned this security breach and every breach like this.
The next Slashdot story will be ready soon, but subscribers can beat the rush and slashdot the links early!
Hum, look at the references section
6. http://www.kb.cert.org/vuls/id/192995
7. file://localhost/XDR.html#vendors
8. http://www.kb.cert.org/vuls/id/516825
localhost!? They're obviously already using the vulnerability to put files on my computer.
.oO Kaa Oo.
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
Note that isn't one of Slashdot's conspiracy theories. If you report something to CERT/CC for free, they sell it to their subscribers.
Unfortunately, this process is not defined in a way that is transparent for those who contact CERT/CC. I've seen conflicting reports regarding the question whether this sharing is mandatory or optional, implicit or explicit. Not surprisingly, the CERT/CC website is not very helpful:
(From the CERT/CC FAQ.)