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.
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*
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.
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.
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.
Javascript sucks. Perl is perfect!
If only mod_perl weren't such a motherbitch, perl would be perfect.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
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.
(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.