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.
You don't need a lab coat or even a lab to research.
Free Martian Whores!
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.
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/
As someone who he released a vulnerability for this weekend, and the person responsible for security of the product in question...
I WOULD VERY MUCH LIKE IF HE WOULD NOTIFY US (the affected vendor) AT LEAST AT THE SAME TIME HE PUBLICLY RELEASES IT!!!
We found out via support cases coming in from clients who were reading FullDisclosure before I got into the office to check my morning emails. NOT COOL!
If Oracle doesn't have someone reading FullDisclosure every day, including the weekends, you deserve to be embarrassed and shamed by your customers. Hint: someone from the MariaDB team was adding to the discussion already by Sunday.
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.