Researcher Discloses New Batch of MySQL Vulnerabilities 76
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."
You deserve it! (Score:3, Insightful)
Re:At the risk of getting modded down... (Score:5, Insightful)
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.
Re:At the risk of getting modded down... (Score:5, Insightful)
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.
Re:Researchers use responsible disclosure (Score:2, Insightful)
We found out via support cases coming in from clients who were reading FullDisclosure before I got into the office to check my morning email
...and you think it's somehow reasonable for a "person responsible for security" to sit back and wait for vulnerability reports to find their way through product support channels, instead of monitoring FullDisclosure?
Re:Researchers use responsible disclosure (Score:4, Insightful)
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 [seclists.org] already by Sunday.
Re:Researchers use responsible disclosure (Score:2, Insightful)
Well, it was after 11PM local time, I'm sorry if I sleep.
Now you want advance notice based on your timezone... this is called "moving the goalpost".
Originally you said: "I WOULD VERY MUCH LIKE IF HE WOULD NOTIFY US (the affected vendor) AT LEAST AT THE SAME TIME HE PUBLICLY RELEASES IT!!!"
There's an easy solution to that:
1: Subscribe to FD.
2: There, now you're being notified at the same time as the public.
Only improperly configured installations? (Score:4, Insightful)
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.