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."
is someone who spends their working day just trying to poke holes and find vulnerabilities in software a "researcher"?
Yes. Much like people trying to poke holes in other people's scientific research are scientists.
Ezekiel 23:20
If it's so easy, why aren't you doing it and making money turning in chrome flaws to google? or firefox flaws to mozilla? Or Ie flags to microsoft? They all pay for real vulnerabilities.
The answer: It's not easy. There is no magic "penetration program". It requires detailed knowledge of processors, compilers, and software architecture. It requires skills that you won't learn in most colleges (R/E). It requires patience. It requires methodical documentation to be good at it. And at the end of the day, there is absolutely zero guarantee that you will find any vulnerabilities or that a vulnerability even exists.
No, but you need a bow tie to be the doctor...because bow ties are cool.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
If you're running Windows, you can default to "yes".
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
Right, suggestions like the Zenoss commentor who says "f you dont want to frack around, just chmod those puppies 777" are the reason why this is a problem. It's sadly common advice in the "I want setup to be easy" land of MySQL priorities.
Note that if you change the directory a PostgreSQL server writes to so that other users are allowed to write there, too, the server will refuse to start until you fix the permissions so that isn't the case. New database installations made with initdb have the right permissions, but the code checks against people "fracking" themselves by making them less secure later. The only way around this is to modify the source code to disable the check!
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.