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: (Score:1)
You deserve it when you run crappy software that needs a firewall in front of it to be minimally safe.
Especially when that software has to enforce internal permissions and boundaries.
Sorry, but I'm pretty sick of these excuses for garbage code.
Re: (Score:2)
Re: (Score:1)
Car analogy time! Ever get stuck behind a tractor driving 5 mph, carrying a fully loaded manure spreader dripping all over? Then you try to pass him but all the fumes have made you high and you crash your car. You wake up and find yourself chained up in a farmer's sex dungeon and he proceeds to sodomize you for 3 months until you finally die of an impaled rectum.
Well, maybe your car shouldn't be on the road either!
My God (Score:2)
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.
Re: (Score:2)
You do not need a firewall, just listen to local IP addresses, not the public Internet one ;-)
Re: (Score:1)
Agreed. If it weren't for 'researchers' like Slouches-With-Pizza, here, we wouldn't have to worry about computer crime at all.
Re: (Score:3)
You don't need a lab coat or even a lab to research.
Re:At the risk of getting modded down... (Score:5, Funny)
No, but you need a bow tie to be the doctor...because bow ties are cool.
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.
Perhaps because its boring? (Score:2)
Creating something is a lot more fun than picking it apart.
Re: (Score:1)
... 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.
So you are unwilling to qualify a fat guy slouching with pizza dripping down his face who finds 7 vulnerabilities in MySQL during the weekend as a "researcher", and give the title to a Monday-Friday 9:00AM-5:00PM labcoat wearer who (probably hates his job and) believes MySQL is secure? Why?
FWIW the fat guy also found 4 other vulnerabilities in other software.
If running some other person's software to find these vulnerabilities is so damn easy, how come the guys with the fancy labcoats didn't find them soone
Re: (Score:2)
If running some other person's software to find these vulnerabilities is so damn easy, how come the guys with the fancy labcoats didn't find them sooner?
That's the question that the survivors picking their way through the rubble of the Internet will be asking in a few years.
It's not like these vulnerabilities are hard to find, as evidenced by the constant flood of discoveries by tiny private research groups. Yet our current best-of-breed million-dollar industrial-strength software development industry swears it's absolutely impossible / impractical to do it at any cost. And the academic software engineering community apparently agrees.
Something does not add
Om nom nom (Score:3)
The troll eats well today...
Re: (Score:2)
If they would have said "hacker" there would have been another debate about if that word were used correctly. Neither debate matters because everyone but the stupid pendant gallery understood what was meant and that language is a mailable medium that relies heavily on context.
Also, the stereotyping certainly doesn't make your argument stronger. It simply makes you look like a clueless outsider that gets his bearings from Hollywood and Internet memes.
Re: (Score:2)
Hey you know what's under a labcoat? A pizza-stained shirt. From slouching and eating it while running an experiment with someone else's discoveries.
Researchers use responsible disclosure (Score:2)
Re: (Score:2)
A look at the twitter feed [twitter.com] of the submitter and his associated web site--"Farlight Elite Hackers Legacy"--does not give the impression of responsible disclosure. But this is the same guy who released the 2010 “Apache Killer” [tallpoppygroup.com]; calling attention to problems with exploit code is this guy's method. I'd rather see that than no disclosure at all. He does appear to be a professional penetration tester at work, who does things like speak at conferences [wordpress.com] on his methods too.
Re: (Score:2)
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!
Re: (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: (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.
Re: (Score:2)
THREE MONTHS?!?
That's insane. Maybe it was appropriate in the 1980s when "security researchers" and "black-hat hackers" were sets of bored grad students with slightly different moral compasses, but now with various governments and criminal enterprises buying up exploits, one should probably just assume that anything disclosed publicly is also for sale from another "vendor" or already packaged into as-yet-undetected malware.
As for sleep, it sounds like somebody has created an expectation of 24x7 on-call sec
Re: (Score:2)
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.
There's an even easier solution:
0. Don't introduce security vulnerabilities into your own product to start with.
We have compilers and testing suites for a reason. Use them. And if your language and testing toolchain are insufficient to the job of making sure your product does not endanger the entire Internet, then use a better one. If your architecture doesn't allow you to write provably secure code, write a better one.
It's 2012. There's no excuse for this anymore. Do it right, or don't put your code on th
Re: (Score:2)
The first rule of software is that all software beyond the barest of trivial examples will have bugs. Compilers are software, and have the same long and sordid history of bugs. Since compilers have been mentioned specifically, you might be interested in the classic work Reflections on Trusting Trust [bell-labs.com] (it was apparently written by a guy who knows a thing or two about the topic, some Ken Thompson fellow).The same goes for test suites. In many cases, bugs translate to security vulnerabilities. In some cases, pe
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: (Score:2)
I used to handle ALL of these issues for a very large vendor. Yes, people did wake me up over things, until I wised up that my employer's problems during my off hours were in fact my employer's problems, not mine, and that my employer as an institution didn't give a fuck about anything but saving face.
I quit about the time vendors started trying to dodge responsibility by talking about other people's "responsible disclosure".
You are not entitled to know about a problem before those who are actually affecte
Re: (Score:2)
Nope, but I didn't whine about it.
Re: (Score:2)
As someone who he released a vulnerability for this weekend, and the person responsible for security of the product in question...
... shouldn't you be apologising for not finding the vulnerability in your own product yourself?
You've got the source code, all the architecture notes, the people who wrote it, the comprehensive testing suites... and yet you still let a critical security error get through that some random guy on the street with a $10 fuzzer found by accident.
There's a problem here, and it's not with the security researcher. Sorry.
Re: (Score:2)
Hold it. You don't monitor full disclosure security websites yourself?
It's called "Intel". It's worth the effort.
Full disclosure is only a problem if you don't take advantage of it yourself. Otherwise, it's embarrasing when your customers do your job for you, or when the blackhats do a little personal disclosure on your assets.
Yeah, yeah, I know. There aren't enough hours in the day, you don't have enough staff, etc., etc. That just means management isn't prioritizing and allocating correctly. That still me
Privilege Elevation bug not much of a bug (Score:3)
Re:Privilege Elevation bug not much of a bug (Score:5, Interesting)
Right, suggestions like the Zenoss commentor [zenoss.org] 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 [postgresql.org] 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 [nabble.com] to disable the check!
Re: (Score:1)
Just like the world is full of "developers" who write everything to c:\temp, the world is full of Unix hacks who chmod 777 everything "because then it works".
Re: (Score:1)
Re: (Score:2)
"I haven't done much windows development, are the semantics of C:\temp different from /tmp? Why is writing to it a bad idea?"
It's bad idea for at least two reasons: /tmp for that matter. You should write to %TEMP% or $TMP instead.
1) You should never write to C:\temp, or
2) Even if you write to %TEMP%, please think twice what you write there and where exactly within: i.e. to a non-predictable file name.
Re: (Score:2)
Writing to tmp breaks encapsulation, and so it is considered more "dangerous" than setting up your own internal temporary storage mechanism. File name collisions are the most obvious issue to arise from this. In worse cases, you can leak sensitive information (I remember one of the GUI terminals in Gnome was dumping the buffer as plain text to tmp, even when using SSL).
Re: (Score:2)
Writing to tmp breaks encapsulation, and so it is considered more "dangerous" than setting up your own internal temporary storage mechanism.
Race conditions like c:\temp and /tmp are an example of why the current 40-year-old operating system model we have, with lots of secure processes but all using a big shared filesystem, needs a long overdue rethink. And we're missing the chance to do it with the best opportunity we have - tablets - because they're inheriting the same fundamentally broken OS design.
Another big other example of why our OSes need a rethink is virtualisation. It shouldn't have to take simulating an entire CPU, motherboard and OS
Re: (Score:1)
Re: (Score:2)
Or the Linux hacks who disable SELinux because they can't figure out how to create exceptions or fix the file system labeling problems.
Re: (Score:1)
C:\>dir /var/lib/mysql//
Invalid switch - "var".
What is going on here? Is my system vulnerable or not?
Re:Privilege Elevation bug not much of a bug (Score:5, Funny)
If you're running Windows, you can default to "yes".
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.
Re: (Score:2)
If you leave 3306 open to the Internet, yes, that would be an improper configuration and you kind of get what you deserve there.
Why? Why do you "deserve" that the database is not safe to use that way? Shouldn't it be? If not, why it should not be safe?
I think this is the main reason why every fucking application from browsers to document viewers to databases to webapps to firewalls to php's are buggy: developers assume "it will be protected by other means, I don't need to check my code or sanitize input. They'll use apparmor. it is not that serious a hole".