Slashdot Mirror
Drupal Warns Users of Mass, Automated Attacks On Critical Flaw
Trailrunner7 writes The maintainers of the Drupal content management system are warning users that any site owners who haven't patched a critical vulnerability in Drupal Core disclosed earlier this month should consider their sites to be compromised. The vulnerability, which became public on Oct. 15, is a SQL injection flaw in a Drupal module that's designed specifically to help prevent SQL injection attacks. Shortly after the disclosure of the vulnerability, attackers began exploiting it using automated attacks. One of the factors that makes this vulnerability so problematic is that it allows an attacker to compromise a target site without needing an account and there may be no trace of the attack afterward.
Would this be actual irony, as opposed to Alanis Morrissette irony?
Do not look into laser with remaining eye.
worked with an older version of drupal ages ago..
Not a surprise the code quality and design was fucking awful then, and I wouldn't expect it to be any better now if the same coders made V7
They were set up by trying to roll their own sql sanitation code instead of just using the existing prepared statements options that PHP has. Did they write their own AES implementation as well?
Neither security through obscurity nor "not invented here" syndrome are my favorite things, but I've learned to stay away from these PHP frameworks because you can stay up 24/7 and still not patch in time. Same goes with phpBB or vBulletin or whatever. Inevitably there are core vulnerabilities discovered and they spread rapid fire through automation. I sleep easier knowing that while my own team's code surely isn't perfect, any critical errors are our own, are unique to our surface, and can't be discovered/wormed/exploited through automated google searching. If you're going to build a large PHP web presence, hire competent developers and do it yourself.
The story only mentions Drupal 7. Is Drupal 6 or 8 impacted?
How do prepared statements handle the not uncommon situation where you want to include an "in" clause? For example:
select * from customers where city in ?citylist
This was the problem they tried to solve by dynamically creating a statement like:
select * from customers where city in (?city-1, ?city-2, ?city-3)
So, to generate the -1, -2, and -3 parts they relied upon the index of the array.
Only in PHP an array will turn around and bite you with it's dual personality as a hash table. A hash table where one key was not "-1" but rathersomething like (pseudo):
-1); drop table students; --
You cannot really fault the Drupal developers for trying to support this commonly occurring pattern, for which there are no good solutions with plain prepared statements. After all, if they could write secure code for a common problem that could prevent less experienced developers for falling back to error-prone and insecure string interpolation.
Don't get me wrong: The drupal developers is at fault. But they were set up by the criminally insecure PHP.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I have never seen any php apps that run fast. PHP is crap. They are all a magnitude slower than javascript . Javascript sucks. Perl is perfect!
Microsoft SQL Server has both an XML data type and a table-valued parameter that can be used to pass an arbitrarily long list of values in a single parameter. Does MySQL not have an equivalent, or maybe it does and PHP doesn't support them?
I'm surprised it took this long! While not a PHP programmer, I've looked at some bits of the code and it's a bloody mess.
php should get a new motto: "Please Hijack our Platform"
Yes Francis, the world has gone crazy.
Spot on.
Sony haven't learned from the 2008 and 2011 lack of input sanitation. Today we learn customer data is available from yet another SQL injection attack. They've been sitting on it for a couple of weeks, it remains exploitable.
Give if half a day before the press bothers to report on it.
Tip to moderators: There is no mod category "Sad". The best response is to ignore it, because then those who can recognize a completely unmoderated post will appreciate the metahumor.
I sometimes ask revealing, often ignorant-seeming questions. Maybe they're harder to answer than you think.
I did some websites in Drupal, but now I am steering clear of Drupal and the likes (Wordpress,...)
Now 100% of my projects are in my custom CMS where obfuscation is the rule.
The Drupal developers could have cast the hash key to an Int, then that problem would not exist.
How do prepared statements handle the not uncommon situation where you want to include an "in" clause? For example:
select * from customers where city in ?citylist
This was the problem they tried to solve by dynamically creating a statement like:
select * from customers where city in (?city-1, ?city-2, ?city-3)
So, to generate the -1, -2, and -3 parts they relied upon the index of the array.
...
for which there are no good solutions with plain prepared statements.
...
Bullshit. Psuedo code cause I'm too lazy to look up the php-ism for this:
$stmt = "select * from customers where city in (".join(',', map { '?' } array_values($city_list) ).")";
$sth = $db->prepare($stmt);
$sth->ececute(array_values($city_list));
Wrapper code to aid in building the placeholder stuff should be used to account for max count of items (generally 255 of them), after which it should split it to: ...) OR city in (?,?,? ... etc ...) )
( city in (?,?,?... etc
Does that take work? yes. Is it more effort than what they're doing? no.
What a cheap flame. And how not original. And you're wrong. SQL injections can be done with every language. To solve this, all it takes is a programmer who understands what he's doing and knows about a vulnerability that has been known for about 20 years and for which there is NO excuse for not knowing it.
It's not really hard do to it right, even in PHP. And there is a simple proof for that.
It doesn't have to be like this. All we need to do is make sure we keep talking.
While the responsibility for this rests with Drupal, they were set up by another strange design decision of PHP: The fact that arrays are also hashtables and vice-versa. There are *tons* of these strange design decisions in PHP.
That one, at least, seems designed to copy a feature of perl, and therefore it's completely understandable...
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
LOL, that's a perfect characterization. Good work! I did actually laugh.
my $sql = 'SELECT * FROM foo WHERE bar IN (' .join(',', ('?') x @array) . ')';
Totally hard.
Your hair look like poop, Bob! - Wanker.
Is the White House breach a result of this bug? Inquiring minds want to know!
XML would not be a standard SQL construct. Neither the PHP-internal mssql driver nor the microsoft PHP driver supports TVP.
The postgresql way to prepare a statement that needs to do something like "... field IN ($1) ..." is to rewrite it as an array operation "... field = ANY ( $1 ) ..." where $1 would be an array, but PHP/PDO can't properly/securely prepare this since it doesn't understand array operations. You would need to manually escape each element and create a literal array string in your code and pass that as the parameter:
Note that a varchar[] in PHP would look something like "{Smith,O'Hare,Wilkerson\\, Esq.}" so none of the normal SQL escaping functions would work properly (note that single quotes are not escaped, but commas and curly braces would be escaped).
I think postgresql arrays are slightly nonstandard (you can declare them using "datatype ARRAY[size]" but postgresql does not enforce array bounds. MySQL does not do array datatypes at all.
If I have been able to see further than others, it is because I bought a pair of binoculars.
All software that has drupals deployment rate has suffered security issues.
Would it take rewriting the entire db interface to not used named placeholders? Yes.
The original advisory notes that "Since Drupal uses PDO, multi-queries are allowed." I can find documentation that confirms that's true of the MySQL PDO adapter. Is that also true for PDO for other databases, or is this vulnerability specific to MySQL?
While the responsibility for this rests with Drupal, they were set up by another strange design decision of PHP: The fact that arrays are also hashtables and vice-versa. There are *tons* of these strange design decisions in PHP.
That one, at least, seems designed to copy a feature of perl, and therefore it's completely understandable...
Er, no. Where did you get that idea? Perl has distinct array and hash data types, and though Perl has a liberal approach to reading variable values ('$scalar = @array' does... interesting things, for example), there is a clear distinction between the two.
Crumb's Corollary: Never bring a knife to a bun fight.
Anyone see that Bash Vulnerability? Or how about that SSL vulnerability? Millions of systems were compromised.
While the responsibility for this rests with unwashed Linux basement dwellers, they were set up by another strange design decision of Linux: The fact that Linux software is filled with 1000's of unnamed 0-days due to shoddy coding decisions in Linux.
Frankly, if you are writing out SQL statements by hand, you probably are not qualified to comment on the relative merits of PHP to other languages.
I guess if you are programming for facebook or somebody you might hit a corner case where you need to fine-tune your ORM's SQL generation (you _are_ using an ORM, right?), but in that case you should know how to handle simple corner cases like this. For this one, you could do this:
$sql = 'SELECT * FROM tbl WHERE id IN ('. implode(', ', array_fill(0, count($user_inputs), '?')) .')';
$query = $pdo->prepare($sql);
$query->bindValues(array_values($user_inputs));
(you _are_ using an ORM, right?)
Of course! I've got this one that came with my framework called Drupal.... oh wait.
For this one, you could do this:
You could, but you're throwing away the "prepared" half of "prepared statement". Totally fine if its a one-off query. Otherwise, expect your DBA to appear behind you, breathing down your neck with a red-hot poker 3 milliseconds after you put that in a loop from 1 to 10,000.
If I have been able to see further than others, it is because I bought a pair of binoculars.
MSSQL is also horribly insecure. After one of our sites at work got exploited from a 0 day, and the vulnerability STILL hasn't been patched after months, we moved EVERYTHING off of Windows server.