Slashdot Mirror
Firm To Release Database, Web Server 0-Days
krebsonsecurity writes "January promises to be a busy month for Web server and database administrators alike: A security research firm in Russia says it plans to release information about a slew of previously undocumented vulnerabilities in several widely-used commercial software products, including MySQL, Tivoli, IBM DB2, Sun Directory, and a host of others, writes krebsonsecurity.com. From the blog: 'After working with the vendors long enough, we've come to conclusion that, to put it simply, it is a waste of time. Now, we do not contact with vendors and do not support so-called "responsible disclosure" policy,' Legerov said."
Firm To Drop Database, Web Server 0-Days
The verb to drop has specific meaning w.r.t. databases. A few more words in the title would have been acceptable. How about:
Fed-up security firm to release Database & Web Server vulnerabilities publicly
Look at how much more information is conveyed in that second title. A work of beauty, it is.
coding is life
FTFA:
At issue is the pesky ethical and practical question of whether airing a software vendor’s dirty laundry (the unpatched security flaws that they know about but haven’t fixed yet) forces the affected vendor to fix the problem faster than it would have had the problem remained a relative secret
Hasn't this been proven to be true - and legal?
In all honesty, if they've contacted the vendor and the vendor hasn't patched it in a month or two, I think its completely ethical and practical to release the vulnerabilities. After all, there could be a few other small firms who have discovered the vulnerability and are exploiting it. Best to put them out there in a Twitter feed so that the entire world instantly complains about it forcing the vendor to fix it. I prefer security over new features.
The alternative to irresponsible disclosure is for the vulnerability to be used maliciously for an unknown period of time. Which of those is preferable?
Here's a quote from TFA...
Legerov said. For example, he said, “there will be published two years old Realplayer vulnerability soon, which we handled in a responsible way [and] contacted with a vendor.”
I think that apparently the vendors aren't doing a damn thing to patch a good amount of these reported vulnerabilities if they are being reported in a proactive manner. Seems as if once the exploits are running rampant in the wild then the vendors scramble to develop patches. Not the best business practices all the way around, but it's the way it is.
Yes, because it coerces vendors to fix vulns and therefore improves ecosystem health.
If the internet ecosystem were not under steady attack, it would be weak and much more vulnerable.
What does not kill it makes it stronger.
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
To clarify the summary, this guy isn't saying that he's not going to wait for companies to fix exploits before he releases them; he's saying he's not going to tell the companies at all. That, in my opinion, is very irresponsible. If you contact them and say you're going to release the information in 90 days regardless of their progress on a patch, fine, but to not warn them because of a few vendors who don't do their job is harmful to everyone.
Responsible Disclosure is like "pro choice" or "pro life". It is a deliberately positive term for purely demagogic reasons. You can't be for irresponsible disclosure, just like you can't be against choice or against life.
The protocol for publishing information about exploitable software bugs is an intensely debated topic and the choices affect multi-billion dollar businesses where it hurts them most: The bottom line. Do not for a second believe that anyone in this game argues for the sake of rational discourse alone.
This is like punishment.
The irresponsible party in this case, is the software vendor. If the vendor can't clean up their act, and at least work on fixing 0-day exploits, then public disclosure/humiliation is probably a good way to get at least some vendor to sit up, take note and do the right thing the next time around.
This sounds like a good case for establishing a procedure.
1. Contact vendor about exploit, with an expiry date.
2. Release information about exploit once date has expired, irrespective of whether bug is fixed, and the fix deployed.
Is there perhaps a clearing house for such things?
Some firm draws up a press release that they're going to drop the bomb on every piece of software they could get their hands on that is used everywhere in the world for one thing or another.
Right, what are they selling again?
"I use a Mac because I'm just better than you are."
Yes, because "responsible" goes both ways. They're being responsible by notifying the vendor before going public. If the vendor is not fixing the issue, it's time to go public.
As far as I'm concerned a public release is still a responsible one. At least in that case everyone knows about it.
Irresponsible is selling unknown vulnerabilities to private parties that will use them for their own gain. The vendor's customer's get screwed and the vendor has no idea that it's even happening.
"Pay attention to us, we'll disclose everything up front before everyone else! BTW, here's our products and services."
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
Or is the English language dying a painful death on /. as time passes. The past day's article summaries and headlines are a blend between Yoda backing off the chronic and the broken English that some toy assembly manuals convey.
Seriously, it took me three passes at reading this article headline to understand what the hell it meant. Maybe that's part of the entertainment value that I'm missing???
The term "responsible disclosure" is newspeak for "keep your mouth shut". The alternative to 'responsible disclosure' is that the vulnerabilties continue to exist for sometimes years, with wild exploits happening perhaps unknown for long periods of time.
I think it's okay to notify the company and give them time to fix the bug, but time on the order of years is completely unreasonable. On the Internet, a year is a very, very long time.
My blog
I welcome this.
In ancient ages past, we put up with "It's a theoretical attack, no one could actually execute it"...
to "group X has released a THEORETICAL working example of an attack to the public, so we fix it six months after revealing it to us"...
to "Here is how you fail... here is how to make you fail... FAIL!!!"
'responsible disclosure' is just wearing the nice guy badge...
You're the only one wearing the nice guy badge.
I'd rather see "Oh CRAP! This thing in Word is broken!" "Oh CRAP! This thing in Excell is broken!" "Oh CRAP! I went to look at a brittany spears vid and now can't move my mouse! Why is my DSL light blinking a lot?"
And then see it fixed in a day or two (at most), rather than a month or two (if we're lucky).
God forbid vendors actually start testing their software *before* it's in the field.
Care about electronic freedom? Consider donating to the EFF!
This is one of those issues where the instinct of any good capitalist is to privatize benefit and socialize risk. When you screw up in the auto industry, the company faces the massive expense of a product recall. That helps to keep you honest with your engineering quality.
I personally think 30 days is a reasonable notification period. Not pleasant for the vendor to have to respond that briskly, but this isn't about being pleasant. If the vendor wants pleasant, they should invest more competence in the original product. This isn't easy, and might move a few pointy-haired managers out of the executive suite.
Probably a more viable compromise is eight weeks. This adds a thin margin for the possibility that key zero-day SWAT staff are booked off, that multiple issues are raised concurrently, or that a product has a stupendously long build cycle.
I would be thrilled to see an industry standard put in place where everyone knows the ethical notice period is eight weeks, period, perhaps with the odd extension on a track record of good behaviour.
I would also like to see proprietary TCO calculations updated with a term to account for the customer disruption of having to rapidly deploy a not-tested-for-months-at-a-time critical vulnerability patch.
Speaking of which, that whole TCO thing really bends my biscuits. It's just loaded with sly neglect of not entirely apparent costs, of which the year-long critical vulnerability update is one of the more egregious.
During that time, your pants are down if anyone less ethical discovers the same flaw. It never happens that two scientists make the same discovery in the same year and end up in priority dispute, according to the industry of socialized risk.
I think that apparently the vendors aren't doing a damn thing to patch a good amount of these reported vulnerabilities if they are being reported in a proactive manner. Seems as if once the exploits are running rampant in the wild then the vendors scramble to develop patches. Not the best business practices all the way around, but it's the way it is.
It's most likely a case of resource management and insufficient resources available. Businesses exist to make money. Features make money, bugs cost money. So, given NNN amount of money, do you:
A) Fix the bugs that people are experiencing problems with RIGHT NOW with exploits in the wild, or
B) Fix the bugs that are "theoretical" and MAY be exploited at some point in the future if somebody else finds it?
Now, the clueful would note that the set of B includes the set of A, but for those who are living close to the edge, A is where the attention goes, and that's why you see announcements like this one.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Agreed - inform the vendor with all the details. Same day, publicly announce that the vulnerability has been discovered, but with no details. At a specified date (60-90 days later) make full details public.
Sounds so simple, doesn't it?
This guy should rename his name to Bobby Tables at the same time. Imagine the number of newspapers that would try to do a press release, but couldn't.
It seems only slightly less irresponsible to publicly disclose exploits without making companies aware of them than it is for companies to disregard known security flaws in their own products.
RFPolicy struck me as the best compromise, but maybe there's room for a third-party service to hold exploit information in escrow for a defined period of time then release it. If a company knew that they had a couple of months to fix a problem at the outset, and that nothing was going to stop publication, that could provide additional encouragement to address the problem.
At the expense, of course, of being a really crappy way to treat companies who ARE proactive about their security issues, especially as a security researcher doesn't always necessarily have the full picture of what's necessary to fix the problem in cases where it's intertwined with required software features. That's probably the most significant aspect of RFPolicy -- the dialogue and collaboration between security researcher and software developer to determine the scope of the problem and the potential solutions.
Let's not go there. The point is that calling it "responsible disclosure" makes arguing against it much harder than, for example, calling it "delayed disclosure" would.
Yes, but it's unrealistic to expect that if researchers didn't publish attacks, there wouldn't be any.
Somebody found the hole. It can't be that they're the only person on the planet who could possibly figure it out. Eventually somebody else will find it too, or maybe already has. If that person happens to have something malicious in mind, they won't publically disclose it. They'll exploit it for their own gain, or sell the information to people who will do that.
If nobody disclosed vulnerabilities for the public's benefit, they'd never get disclosed until somebody got hit with them. First somebody would perform a successful attack, and a postmortem examination would eventually result in figuring out what happened. But doing things this way means at least one victim is 100% guaranteed, and nobody can prepare for it in advance.
Basically what this is about is choice. The companies in question have been notified of the security flaws in their product. They have as of yet fixed said flaws. They have instead prioritized other projects above fixing the bugs. The choice was given to the companies in question. The choice is now being removed due to their inaction.
I will take irresponsible disclosure any day over people not fixing known bugs. This is forcing their hand and that is why they don't like it.
All in all, tough shit for the companies involved.
In an ideal world security flaws would be fixed when they are discovered. I think we can all agree this is not an ideal world.
IMAGE VERIFICATION IS EVIL!
It's most likely a case of resource management and insufficient resources available. Businesses exist to make money.
And as long as we keep putting up with shoddy software, they'll continue to sell it to us. Bugs cost money, as you said, so I would think they might put a few more resources to getting rid of the bugs before they shovel it out the door.
Free Martian Whores!
I am in favor of mandatory masturbation (to prevent the need for abortions.)
If more firms paid bounties for bugs found (as long as responsible disclosure is followed), you'd probably see a whole lot more security researchers content to follow responsible disclosure guidelines. There's no guarantee that they'll keep that all a secret in any case, but to get the cash, you've got to sign a legal form with your company's information or be registered as a valid security analysis firm. One of the biggest issues with these security analysis firms is that there's no way to tell most of the time if it's just a bunch of criminals hiding out under a corporate umbrella, or if they're bonafide security professionals. And no jokes about them being one and the same...there's a huge difference, I've known (and in the case of those pros, I've worked with them) guys from both sides. If a security firm refuses to be registered or refuses bounties, you know there's something fishy about them and it's time to contact local authorities.
Then again, there's the big problem with many of the bugs that outside security firms reporting being already known and in a work backlog. The realities of the industry is that capital isn't unlimited, time isn't unlimited, and sometimes, important stuff doesn't get done because you just don't have enough qualified developers to throw at the problem. Two years is fairly excessive for a security hole to sit around, but if a security firm is releasing exploits that it discovered and reported 6 months prior just because it "didn't see enough getting done", that's not being passionate about security, that's an attempt to commit extortion.
You are asserting that the exploit is '"theoretical" (why the quotes?) and might be used in the future without any evidence that this is even the most common case much less the only case. The problem with an undisclosed vulnerability is that unsuspecting users believe they have more security than in fact they do. They expect, at very least, to be informed when a vulnerability is discovered. While this may be an unrealistic expectation in the current market place, customers should be able make informed decisions and thus operate in the market as their roll demands.
This requires an awful lot of patience and a fair degree of bookkeeping on the part of the submitter. And you're assuming that the organization on the other end of the bug report is actually learning from past mistakes in a cause-and-effect kind of way. "Hey! His report-to-release times are getting shorter! Maybe we should adjust!" In an organization of any size, this will be unnoticed even when pointed out plainly.
The more I think about it, the more receptive I get to this fellow's approach. Maybe after a while of "irresponsible disclosure" vendors will pay attention and he can fall back to giving advance notice.
Get off my lawn.
I think that apparently the vendors aren't doing a damn thing to patch a good amount of these reported vulnerabilities if they are being reported in a proactive manner. Seems as if once the exploits are running rampant in the wild then the vendors scramble to develop patches. Not the best business practices all the way around, but it's the way it is.
I'd feed better if, rather than lumping all the vendors together and 0-day disclosing vulnerabilities found in any of them, Intevydis tracked which vendors failed to respond and continued to give the others warning.
Maybe a 3-strikes policy. Or (for vendors with large products and lots of opportunities for bugs) a percentage of slow/no vs. fast fixes.
And the newbies should be assumed responsive until proven otherwise.
Seems to me that would put even more pressure on companies to be responsive, by giving the responsive among their competitors two additional advantages:
- time to fix the bug, and
- customer perception that the unresponsive vendor might be subject to sudden attacks due to disclosed vulnerabilities when the responsive vendor would both get warnings and have a track record of fixing before disclosure.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
This doesn't sound like either responsible or irresponsible disclosure. It sounds like plain old extortion. Notice he does not say he provided the vendor with the vulnerability info, just that he contacted the vendor. Calling a vendor and saying 'you have a vulnerability, pay me x and I will tell you what it is, don't pay and I'll tell everyone else' is not 'being responsible', it is extortion. Given that he must now resort to a blanket 'from now on I'll just release it' threat he must be getting pretty desperate. Frankly, I have no trouble believing that IBM/Tivoli and Sun/Mysql would not bat an eye at an extortion attempt, but I find it hard to believe they would not fix an actual vulnerability if it was reported as such.
Clearly the balance of incentives has been wildly off for some time now. Researchers finding possibly big-cost vulnerabilities and reporting them to vendors/middlemen have found that the responses to their discoveries have been slow. Additionally, the payouts for these researchers has been relatively low.
They've been slow because companies have very little incentive to actually fix these bugs, provided that the rate of exploitation of these bugs is sufficiently low.
The incentives for a company using commercial software are stacked heavily against disclosure (do they discover the intrusion? angry customers upon disclosure? etc.), and software vendors are rarely motivated by costs that are, probabilistically, very low. Only once companies are hit by the overwhelming stigma of wide-spread exploits, and the long tail of consumer distrust, do they take greater care in the future.
Companies these days get the sense that they can dodge 180 days of exposure for the price of a used Honda Accord, but the reality is that knowledge of the bug may not be a significant contributor to the risk of exploitation. If one honest researcher has found a vulnerability, can we be confident that no malicious researchers have? Hell, every little wanna-be hacker and future programmer among us used to have floppies and notebooks of vulnerabilities, some collected, some personally discovered. The vulnerability is the source of risk. Put the blame back on the companies that have failed to fix them. More accurately, shift the incentives . With huge shake-ups like mass disclosures, the effect on all companies could be a shift toward more attention being paid to security. To me, it seems like a net win.
FTFY.
FTFY.
Legerov said. For example, he said, “there will be published two years old Realplayer vulnerability soon, which we handled in a responsible way [and] contacted with a vendor.”
I think that apparently the vendors aren't doing a damn thing to patch a good amount of these reported vulnerabilities if they are being reported in a proactive manner. Seems as if once the exploits are running rampant in the wild then the vendors scramble to develop patches
It's most likely a case of resource management and insufficient resources available.
One word can solve the difference between responsible reporting and 0-day motivation:
embargo
The reporting security group still goes through responsible reporting methodology, but add proposed date the details will be reported more fully to the public.
I work for an enterprise-level network device manufacturer, and anyone in that line of work knows damn well that remote vulnerabilities are the harbinger of death if they're not addressed in a timely fashion. Yet, motivation to assign resources to fix it still relies (in part) on whether there is a public exploit or not. So it's with that background that I can say that embargoes work.
We don't know the details, but apparently Intevydis didn't give embargo dates along with their reported vulnerabilities. Now they see what kind of motivation that produces, and so they've set a pseudo-embargo: any time between Jan. 11th and Feb. 1st.
This signature intentionally left unblank.
But how do you know if it's being exploited in the wild or not? Vendors are unlikely to know, security researchers and the anti-virus companies might. The best exploits are written so the end-user doesn't notice anything bad has happened.
And even if it's not, is it wise to wait until AFTER, say, some business notices that their computer/web site gets hacked because of the exploit, stealing a million credit card numbers before the vendor bothers to fix the bug?
Maybe this kind of thing will result in more problems for purchasers in the near term, which may result in more pressure for vendors to produce higher quality software in the longer term? HAHAHA, I made myself laugh at that...
Sleep your way to a whiter smile...date a dentist!
Except he did not contact the vendors. He said in the past he has contacted some and they didn't fix it, so now he has given up on all vendors and does not disclose the information at all for any vendors.
I work for one of the affected projects and can tell you that we did not get contacted by them via any of our normal, well publicized methods (email, phone calls, etc...).
I agree that if a vendor does not reply then it is totally okay to disclose it to force their hand. However, disclosing it immediately to the public and giving the vendor no chance to fix it (even a few days) is wrong imo.
Exactly. The GP is seeing the world in black-and-white, where reality has many gradations in between.
Naive responsible disclosure: give it to the vendors. They do nothing. The bad guys figure it out. Everyone loses.
Irresponsible disclosure: hand out a zero-day to the bad guys. Everyone loses.
Effective responsible disclosure: disclose it to the vendors along with the promise to disclose it publicly on a scheduled date.
It should be noted that the third way is how CERT does things, and is the only way that the end users stand a chance of not getting screwed. It is important to make it clear that the vulnerability will be released to the public on that date no matter what. It is also important to make this date no more than two months in the future. Make the time frame too short and you're accused of creating a zero-day exploit. Make it too long and they won't bother looking at it until a week before, then they'll tell you that they can't fix it in time, and they'll accuse you of creating a zero-day exploit. There's a middle range in which it's close enough to scare the pants off of the manager types but far enough out that the fix can actually happen.
Most importantly, though, if the vendor doesn't fix it, you must disclose it anyway. Otherwise you lose all credibility, and vendors will simply put off fixing the problem because they'll assume that you will keep backing down.
Check out my sci-fi/humor trilogy at PatriotsBooks.
That's really not fair either.
Many bugs that are security related are a result of interactions that people simply didn't think of as possible. While bug free code is desirable, and possible, would you be willing to pay 10 times more for a "provable" product? 100 times more?
Look at the space shuttle code. Provable software with an average of something like 2 man years per line of code on average? Is that realistic for consumer or even pro commercial software?
On the flip side I abhor this type of disclosure as well. I think 0 days should be forwarded to the vendor and given at least 90 days before release. Hell set a timer on it, even say the following timeline would be ok(ish):
discover exploit: notify vendor
notification + 1 week: notify world of nonspecific vuln in product
notification + 1 month: notify world of type of vulnerability
notification + 2 months: notify world of specific vuln
notification + 3 months: notify world with exploit code.
-nB
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
Which is followed by a letter from the firm's legal department ordering you to keep quiet or be sued for far more than you can afford to pay a lawyer to defend you.
Then Mr. Legorov responds with something that says, basically, "sod off" in russian and gets on with his life.
People running the software pull it out of production until there is a fix? Or they mitigate the problem the day the world learns of the exploit?
One thing to keep in mind: all that was necessary to reverse engineer the DNS flaw was Dan Kaminski's mentioning that it existed - within a week several researchers had figured it out.
I don't totally disagree with you but there ARE times when just the knowledge that a flaw exists (or a rough idea of where the flaw exists is sufficient to allow others to figure the flaw out).