… 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.