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."
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?
They could be providing auditing services. Advertising to whole IT world, that they found shitload of them might just say "Hey, we can check if your apps are safe, and perhaps recommend something better if they aren't."
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
Yes, I assumed this was an article about a firm dropping support for a database and webserver without any notice (perhaps a DRM-supplying company or something). Just below this headline is another misleading one, "CES Vendors Kicked Out of Hotels For Showcasing Wares in Room", which suggests they were showing pirated software.
They were most likely allocating those resources to what they perceived as bigger bugs. These security researchers want *their* bugs to have top priority, because it allows them to make a name for themselves. They're no Robin Hoods.
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.
Fed-up Firm to release 0-Day Exploits
Fed-up Firm to release DB and Web Server exploits
Or other hundreds of ways it can be phrased with-in the character limit.
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!
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
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.
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.
comments from TFA:
I think, they are right on spot.
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).