… You are full of shit.
I don’t know how effective your scare-mongering cash-extortion tactics are, but they don’t really help neither your users, nor vendors, nor anyone else.
It all starts when major vulnerability databases start authoritatively spouting out crap like this:
A vulnerability has been reported in MySQL, which can be exploited to compromise a vulnerable system.
The vulnerability is caused due to an unspecified error and can be exploited to cause a buffer overflow. (Secunia)
Or crap like this:
MySQL is prone to a buffer-overflow vulnerability because if fails to perform adequate boundary checks on user-supplied data.
An attacker can leverage this issue to execute arbitrary code within the context of the vulnerable application. Failed exploit attempts will result in a denial-of-service condition. (Securityfocus)
Of course, there must be some reason to publish such claims, right? Of course, if you brought in cash for all these security vendors, they’d definitely tell you that in future they will give you all available updates, but for now:
Due to the very limited available information, it is not possible to suggest an effective workaround.
Why would one post such crap? Because people want to sell things, like vulnerability databases full of rubbish:
A working commercial exploit is available through Intevydis. This exploit is not otherwise publicly available or known to be circulating in the wild (Securityfocus)
This is how the Security Vendor that unleashed this all classifies the vulnerability:
- Name: MySQL 5.x exploit
- Status: 0day
- Details: Remote buffer overflow exploit. Tested on Debian Linux 5.0 with mysql-server 5.0.51a-24+lenny1
- Listener: LINUXMOSDEF
- Platform: Linux x86
If you’d look it up, Debian just had security advisory DSA-1877-1 (released at September 2nd, one day before Secunia and Securityfocus went live with their stuff), which tells us about denial of service and execution of arbitrary code possibility. The +lenny2 package fixes it, the +lenny1 package is vulnerable. At this point, I don’t really have anything against Debian security people – Linux distribution security contacts are always eager to communicate, share, discuss, and, well, admit failures – and as they are not in money extortion business, it is very easy to forgive them. Still, the advisory mentions “potential execution of arbitrary code via format string specifiers”. See, original exploit at milw0rm did mention “format string vulnerability”, which is source of [easily understandable] confusion here.
Various C libraries allow passing %n format specifier to printf() calls, which is:
The number of characters written so far is stored into the integer indicated by the int * (or variant) pointer argument. No argument is converted.
This means that if you allow someone to pass a format string, he can overwrite memory of your application with specially crafted data (though, it isn’t that trivial to exploit it). MySQL though, as it has to be very portable, has its own version of printf, to avoid any OS-specific behaviors, and that implementation does not have %n, which means by passing arbitrary format string you cannot execute arbitrary code. Phew.
So, what is the bug? Let me present you Bug#45790:
- If server has General Query Log enabled (thats very very low percentage of systems out there) and….
- User has right to create databases (which isn’t a right given away to every user out there….) then…
- He can shut down (well, crash) the server!
Summary of this whole security catastrophe in practice would be:
System administrator can shut down MySQL server
My heart pounds and I hurry to upgrade every machine to 5.0.84 (sarcasm aside, do it anyway, it has great fixes ;-).
P.S. I may be wrong, and there is an exploit which will convert your database clusters into botnet zombies, capable of much more than regular botnets – imagine all the multicore servers attached to SANs completely dominating the world. Scary. Thats why we try to work on all security threats – even if it takes quite a few hours too long for what it deserves.
I think its all supply and demand mechanics: either there is demand for such crap or there is no demand for quality information (demand = money).
Uh, this is pretty standard – though perhaps summary – vulnerability reporting. Even less-general, lower-impact items are described in pretty plain, direct language, and most-all identified vulnerabilities are reported, regardless of subjective “severity”. There is often discussion of mitigating circumstances like “most people haven’t configured it that way”, &c.; one of your links even indicates that it is “less critical”.
What do you suggest? That no one reports this (exploitable) vulnerability? Seriously, what’s the alternative?
Another interesting tidbit is that the vulnerability was claimed to have been found by a “security researcher” 8 days after the patch made its way to the commits mailing list. Intriguing…
jsled, I suggest that instead of writing “unspecified remote buffer overflow vulnerability” people would use existing issues with CVE references, and classify as “DoS by authorized user”, and that terms like “arbitrary code execution” would have some basic research first….
Secunia classified this as ‘less critical’ just because it is ‘local network’, not because it knew anything about the vulnerability in this case.
No vulnerability database cared to assess the impact, so they put in most threatening summary.
Jon: yes, yes… ;-)
Domas Mituzas:
“No vulnerability database cared to assess the impact, so they put in most threatening summary.”
That is absurd. A researcher finds a vulnerability in a product like MySQL, says “it’s a remote overflow in 5.x” and you think that VDBs didn’t care to assess the impact? Do you think they should have audited the entire package and tried to find the overflow? If they did, how could they be sure it is the same overflow the researcher found?
You further suggest they should use “Existing issues with CVE references”, which shows you have no idea what the purpose of CVE is. Re-read their goal and focus on “unique identifier”.
Jericho, researcher didn’t find a shit, he inflated (or distorted) debian security advisory claims. Debian security advisory was based on exploit, which was released for already fixed issue (in 5.0.84) of MySQL.
Anyway, piss-researcher was treated seriously by VDB, and VDB is/was announcing to the world that there is remote arbitrary code execution exploit, when there wasn’t.
It is not absurd, unless I am wrong :)
Again, how do you know that the overflow he found is the same one mentioned in the Debian advisory? Several VDBs have been tracking researchers like Evgeny for years, mostly in our own different (non-public) ways. The term most of us use to describe this is ‘researcher confidence’, and that dictates if a given VDB will add an entry based on vague details or not. Evgeny’s history suggests he is not the type of person to use a published source of vulnerability information and re-brand it as his own.
If you have information that makes you so sure he did it this time, post it for all to see. Let the VDBs better adjust their researcher confidence in Evgeny.
Haha, in perfect world those researchers would notify vendor.
In non-perfect world I have my own opinion about VDBs and researchers, who keep information for themselves and use it for cash extortion.
I value my time enough to build something productive, cheers!
I know you already replied to this Domas, but I found it very funny that this happened just a few days after you posted on the same issue :)
http://lists.wikimedia.org/pipermail/foundation-l/2009-September/055132.html