MySQL.com hacked -- via SQL injection
-
http://blog.sucuri.net/2011/03/mysql-com-compromised.html
"It seems their customer view application was used as the entry point. This is where the attackers were able to list the internal databases, tables and password dump. If you have an account on MySQL.com, we recommend changing your passwords ASAP (especially if you like to reuse them across multiple sites).
What is worse is that they also posted the password dump online and some people started to crack it already. Some of the findings are pretty bad, like the password used by MySQL’s Director of Product Management, it is only 4 numbers (6661) long. Multiple admin passwords for blogs.mysql.com were also posted."
No mention if it involved an employee named Bobby Tables
-
Someone clearly forgot to use a prepared statement.
-
@henke37 said:
Someone clearly forgot to use a prepared statement.
Someone clearly forgot to NOT USE MYSQL.
-
@The_Assimilator said:
Someone clearly forgot to NOT USE MYSQL.
Yeah, that would be good advertisement: "Yeah, our product is MySQL, and we're really proud of it. However, we don't use it ourselves, because it's not secure enough. Feel free to use it yourselves though."
-
@derula said:
@The_Assimilator said:
Someone clearly forgot to NOT USE MYSQL.
Yeah, that would be good advertisement: "Yeah, our product is MySQL, and we're really proud of it. However, we don't use it ourselves, because it's not secure enough. Feel free to use it yourselves though."
Well, to be fair, the part of the application that had the vulnerability wasn't MySQL. I guess the next conclusion would be not to ask the people who wrote mysql.com about how to use MySQL.
-
I think it was all a conspiracy instigated by aliens paleontologists video forum mods Oracle in order to scare people away from MySQL and into the clutches of PostreSQL Oracle.
Boy, I'm really bad at writing typing my words today.
-
@The_Assimilator said:
@henke37 said:
Someone clearly forgot to use a prepared statement.
Someone clearly forgot to NOT USE MYSQL.
and what exactly is wrong with mySQL itself?
*Rolleyes* better than a lot of databases out there *cough*oracle*cough*
-
@Xyro said:
I think it was all a conspiracy instigated by aliens paleontologists video forum mods Oracle in order to scare people away from MySQL and into the clutches of PostreSQL Oracle.
You missed
plantsyipyappersperfect-perfectsAccess.
-
@Kazan said:
and what exactly is wrong with mySQL itself?
I had asked the same question earlier. I think the biggest problem is the lack of foreign key support (except for, I think, InnoDB). I mean, how can a developer serious about his work honestly be expected to go without foreign keys, of all things? FKs are one of the most fundamental parts of relational databases.
-
@toth said:
@Kazan said:
and what exactly is wrong with mySQL itself?
I had asked the same question earlier. I think the biggest problem is the lack of foreign key support (except for, I think, InnoDB). I mean, how can a developer serious about his work honestly be expected to go without foreign keys, of all things? FKs are one of the most fundamental parts of relational databases.
A lot of us tried to use older versions when it was, and I'm being generous, BROKEN AS SHIT. It would fuck up your character encodings, truncate data with no warning, every so often it'd lose entire tables for God-knows what reason, lack of many data consistency features.
It just generally was not reliable at all. What you put in may or may not be what comes back out... and if there's ONE thing a DB should do, it's not fuck with your data.
It's actually not a terrible product now, but it's still climbing out of the reputation hole its previous versions dug. But anybody who's had to spend hours and hours and hours fixing character encodings due to DB import (like me) is not going to recommend it for awhile yet.
-
@blakeyrat said:
@toth said:
@Kazan said:
and what exactly is wrong with mySQL itself?
I had asked the same question earlier. I think the biggest problem is the lack of foreign key support (except for, I think, InnoDB). I mean, how can a developer serious about his work honestly be expected to go without foreign keys, of all things? FKs are one of the most fundamental parts of relational databases.
A lot of us tried to use older versions when it was, and I'm being generous, BROKEN AS SHIT. It would fuck up your character encodings, truncate data with no warning, every so often it'd lose entire tables for God-knows what reason, lack of many data consistency features.
It just generally was not reliable at all. What you put in may or may not be what comes back out... and if there's ONE thing a DB should do, it's not fuck with your data.
It's actually not a terrible product now, but it's still climbing out of the reputation hole its previous versions dug. But anybody who's had to spend hours and hours and hours fixing character encodings due to DB import (like me) is not going to recommend it for awhile yet.
that makes sense... i didn't ecounter it until it was in the version 4 stage and we ALWAYS used InnoDB for anything serious. myISAM was only for fucking around.
using InnoDB it was a damn sight better than anything else i ever used, including a certain product that i should be shilling for.
-
If you ever see a website with text like this:
"It doesn’t matter"
You can be virtually certain it's been burned by MySQL character encoding bugs.
-
@blakeyrat said:
If you ever see a website with text like this:
"It doesn’t matter"
You can be virtually certain it's been burned by MySQL character encoding bugs.
Actually those errors can be because of a number of reasons and usually are not due to MySQL being at fault. Wrong text-encoding header is probably 1, followed by wrong editor settings (or a conversion error somewhere in the past) followed by wrongly using PHP's utf8_encode/decode. I'd say then comes mysql error, and likely a lot of those are simply because the settings of the db/table/field are wrong.
Also, [url=http://www.apothekersnieuws.nl/een-kankerstamcel-kan-complete-tumor-vormen/935/]this[/url].
-
Often it feels like character encoding is the bane of my life! The worst was when every character was encoded correctly, with 3 exceptions: ř, Ř and Ň. Took me days to get to the bottom of it! And although it was using MySQL, I don't believe that was the problem (it was a while ago now and I'm not 100% of the cause).
Also - InnoDB is great, but I believe new versions don't include it. I heard it recently from a reliable source, but didn't follow up on it so I could be wrong. Unfortunately, that sounds like MySQL's death knell to me. :(
-
@Mel said:
Also - InnoDB is great, but I believe new versions don't include it. I heard it recently from a reliable source, but didn't follow up on it so I could be wrong.
Uh, what? Quite the opposite, InnoDB became the default engine recently (as in, ~1.5 year ago when 5.5.0 was released)
-
@Mel said:
Often it feels like character encoding is the bane of my life! The worst was when every character was encoded correctly, with 3 exceptions: ř, Ř and Ň. Took me days to get to the bottom of it! And although it was using MySQL, I don't believe that was the problem (it was a while ago now and I'm not 100% of the cause).
Also - InnoDB is great, but I believe new versions don't include it. I heard it recently from a reliable source, but didn't follow up on it so I could be wrong. Unfortunately, that sounds like MySQL's death knell to me. :(
yeah i heard something was up with InnoDB .. but i haven't used mysql in a while. Oracle buying Sun was mySQL's deathknell.. that's why someone fork()'ed mysql. i forget what the fork is called.
-
@blakeyrat said:
You can be virtually certain it's been burned by MySQL character encoding bugs.
I've had a lot of experience with MySQL's encoding issues seeing as I deal with non latin character sets on a daily basis. That crap stopped when we switched everything to UTF-8. I'm talking about db encoding, connection encoding (or whatever it's called) and of course web site encoding. Anyone that still has encoding trouble is either working on shitty legacy databases or is doing it wrong.The only real problem I've had with MySQL is the InnoDB vs MyISAM crap. InnoDB supports transactions but not full text search. MyISAM has full text search support but fails at transactions. It fails badly too since it simply ignores transaction related commands causing countless devs all around the world to waste thousands and thousands of hours chasing their tails.
Still it's not like other dbs don't have problems; a while back I spent literally days debugging an app because that piece of shit they call SQL Server Compact didn't like a particular type of field and would fail with an infinitely helpful message about running out of memory. I still rage when I remember that one...
-
@DOA said:
@blakeyrat said:
You can be virtually certain it's been burned by MySQL character encoding bugs.
I've had a lot of experience with MySQL's encoding issues seeing as I deal with non latin character sets on a daily basis. That crap stopped when we switched everything to UTF-8. I'm talking about db encoding, connection encoding (or whatever it's called) and of course web site encoding. Anyone that still has encoding trouble is either working on shitty legacy databases or is doing it wrong.The problem is when you install something like WordPress, it doesn't know the default collation in the database, and thus is prone to (for example) insert UTF-8 characters into a Latin1 collation database. MySQL doesn't flag an error when you do this, and as long as you're using the same mis-matched collations, it'll also will spit out exactly what you put in, so there's no outward indication that anything's wrong.
Now, WordPress has an option to change its collation, but by the time you realize it's wrong, you've already put in a hundred blog entries which will have gibberish characters if you "fix" the problem. If you try to "fix" the problem by backing up, then restoring, the database, you still get the gibberish. So the only solution at that point is to go through every blog entry to identify gibberish characters, then do a find-and-replace on the entire database to replace the ones you find.
That's the scenario I've seen happen a dozen times to people of varying level of computer ability. It might be fixed now, but as recent as 3 years ago, it was still an extremely easy mistake to make.
And it certainly has nothing to do with the poor soul installing WordPress "doing it wrong." Don't be so condescending. Good software is *impossible* to get wrong. If someone does it wrong, no matter how basic "it" is, that's the software's fault.
@DOA said:
The only real problem I've had with MySQL is the InnoDB vs MyISAM crap. InnoDB supports transactions but not full text search. MyISAM has full text search support but fails at transactions. It fails badly too since it simply ignores transaction related commands causing countless devs all around the world to waste thousands and thousands of hours chasing their tails.
The real question is why MySQL has two entirely different data engines in the first place. Why not just have a single good one?
@DOA said:
Still it's not like other dbs don't have problems; a while back I spent literally days debugging an app because that piece of shit they call SQL Server Compact didn't like a particular type of field and would fail with an infinitely helpful message about running out of memory. I still rage when I remember that one...
Out of curiosity, what type of field was it?
-
@blakeyrat said:
The real question is why MySQL has two entirely different data engines in the first place. Why not just have a single good one?
Who said they only had two? They have like six at last count - the major ones being InnoDB and MyISAM and the rest being emulations of features that would be better implemented in another way. If you go back a few versions, there are EVEN MORE of them which fell out of development, presumably because the one guy that was developing them ragequit the project because his PRECIOUS PRECIOUS FEATURE wasn't getting the attention it deserved.
-
@blakeyrat said:
And it certainly has nothing to do with the poor soul installing WordPress "doing it wrong."
Sorry, I was referring to professionals only. The Wordpress installation of Bob from accounting has fortunately never been something I've had to deal with. Plus the one good thing about using a non latin character set is that when you do it wrong, you know right away. @blakeyrat said:Out of curiosity, what type of field was it?
NText. The workaround is to switch it to nvarchar.
-
@DOA said:
@blakeyrat said:
Out of curiosity, what type of field was it?
NText. The workaround is to switch it to nvarchar.Wasn't NText deprecated like... a decade ago?
I mean, that's not an excuse for it failing, but.
-
@blakeyrat said:
@DOA said:
If you say so... Unlike MySQL I have little experience with SQL Server. Plus it wasn't my design decision, I was only maintaining this particular app.@blakeyrat said:
Out of curiosity, what type of field was it?
NText. The workaround is to switch it to nvarchar.Wasn't NText deprecated like... a decade ago?
I mean, that's not an excuse for it failing, but.
-
@blakeyrat said:
Wasn't NText deprecated like... a decade ago?
... It is?.... Oops. I have a lot of work to do...
-
@blakeyrat said:
And it certainly has nothing to do with the poor soul installing WordPress "doing it wrong." Don't be so condescending. Good software is impossible to get wrong.
Wait -- you're calling WordPress "good software"?!
-
@ender said:
@blakeyrat said:
And it certainly has nothing to do with the poor soul installing WordPress "doing it wrong." Don't be so condescending. Good software is impossible to get wrong.
Wait -- you're calling WordPress "good software"?!Reading Is FUNdamental!
