Slashdot Mirror
Researcher Discloses New Batch of MySQL Vulnerabilities
wiredmikey writes "Over the weekend, a security researcher disclosed seven security vulnerabilities related to MySQL. Of the flaws disclosed, CVE assignments have been issued for five of them. The Red Hat Security Team has opened tracking reports, and according to comments on the Full Disclosure mailing list, Oracle is aware of the zero-days, but has not yet commented on them directly. Researchers who have tested the vulnerabilities themselves state that all of them require that the system administrator failed to properly setup the MySQL server, or the firewall installed in front of it. Yet, they admit that the disclosures are legitimate, and they need to be fixed. One disclosure included details of a user privilege elevation vulnerability, which if exploited could allow an attacker with file permissions the ability to elevate its permissions to that of the MySQL admin user."
When you leave 3306 open on the internet.
... is someone who spends their working day just trying to poke holes and find vulnerabilities in software a "researcher"? Glorified tester maybe but thats about it. I somehow don't think these people hang around in white labcoats in clean rooms with clipboards looking at the latest results. More like some fat guy slouching with a pizza running yet another penetration program that someone else wrote.
"Researcher", insomuch as it implies a level of professionalism, should be reserved for those with a modicum of professionalism, such as responsible disclosure. I could have had my 15 minutes of fame with a vulnerability I discovered that could have been used to take fown wikipedia and many other sites, but instead I reported it through the proper channels so it was fixed, not exploited. Perhaps "security attention-seeker" would be a better term.
The troll eats well today...
0 1 - just my two bits
from what I'm reading the privilege elevation bug requires that you as a non root user be able to write files to a /var/lib/mysql// directory. I dont remember ever seeing a setup where those directories are world writable or where normal non-root users would be added to the mysql group.
http://interserver.net/
Ms. President of Brazil just signed a law that outlaws the development, distribution, dissemination or anything related to "tools to break into computer systems".
There is no provision for researchers. If you are a security researcher, feel free to visit Brazil but bring a lawyer.
"Responsible disclosure" my ass. Call it what it is: delayed disclosure.
I don't trust Oracle, and I'd rather that they didn't know how to hack my servers before I do.
You describe perfectly what a seasoned, experienced developer feels like when he (or she) has to wade through a typical *MP "application" in order to fix and extend it.
Proof Cthulhu is real: *MP kiddies believe view logic is Best Logic.
Yeah, right.
I don't quite agree that this only effects improperly configured installs. If you leave 3306 open to the Internet, yes, that would be an improper configuration and you kind of get what you deserve there.
However, imagine the case of having a webserver open to the world hosting $RANDOM_PHP_APP_OF_THE_DAY, with a MySQL server backend on a separate private network it must talk to. Everything is properly firewalled, only the webapp can access MySQL on 3306, and only has access to it's own database(s) it needs to, and nothing more. Now random exploit for PHP app happens, which gives the attacker access to run their own SQL commands, gain user shell access, whatever. These exploits are common.
This instead of limiting the attacker to the database credentials within the app itself, now gave the attacker full access to the entire MySQL infrastructure bypassing any local ACL's you have in place. Instead of just being able to access your application database, now they can access any other databases setup on the same server.
Most exploits these days are fairly innocuous by themselves - it's when you string them together is where they get to be important. Any attacker worth their salt has lists of thousands of exploitable webapps they are saving for just such days, when a new backend zero day hits. Then they fire up their tools to take advantage first of the known hole in the web application they already scanned for months ago, to then exploit the more severe underlying exploit which is "behind the firewall so we don't care".
Security is a multi-layered thing. You cannot be secure in a bubble, and you cannot say something doesn't effect you just because an attacker can't directly exploit the problem from a random wireless access point in a coffee shop somewhere. Very few exploits I see these days are that "easy" to pull off - they all require multiple exploits used at once, to gain the access needed to the target.
Creating something is a lot more fun than picking it apart.
While most installers do what you say, Google has proven that you don't need Admin privileges to install large software packages (namely Chrome).
But yeah, M$ should kick developers into their assess to get this right.
About 50% of listed exploits (in things like the CVE database) rely on "stressed/lazy/incompetent programmer using C/C++". Buffer overruns, bad pointers, double free()s, accessing bad pointers etc. I would argue that due to human and organization nature, we cannot make the human programmer eliminate these issues dramatically. There will always be a boss around with the agenda of "delivering product to superiour management on time, on budget". That means some poort developers cannot be as diligent as they should be.
But these 50% of CVE issues could be dealt with using technology: Automatic bounds checking, strong typing (no more funny insecure casts), reference-counted memory management (much more to my taste than Garbage Collection, as it happens at defined points in time and is incremental/controlled by programmer). Of course now comes the "C++ Expert" crowd crowing that "this is inefficient and we are so perfect, we don't need it either". Both arguments don't hold water.
First, even experienced guys run their code on valgrind, boundschecker or Purify, because they make mistakes, too. Secondly, even simplistic implementations of bounds checking and refcounting do typically reduce runtime efficiency by about 10 to 20%. Below you will find the URL of a language of mine which proves that. But even that moderate inefficiency could be dramatically reduced by compilers which can prove that a certain check must be done only once instead of for each loop iteration.
http://freecode.com/projects/sappeur-compiler