Drupal Warns Users of Mass, Automated Attacks On Critical Flaw 76
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.
Actual irony? (Score:5, Funny)
Would this be actual irony, as opposed to Alanis Morrissette irony?
Re: (Score:1)
This would be actual irony.
Re: (Score:2)
Re: (Score:3)
... roll-your-own implementations are likely to be broken too.
As far as I can tell, this module uses custom placeholders in queries, and then replaces those with the user supplied values, building a string that can be passed to the DB as SQL without database placeholders. IE. it's not building something like:
$db->prepare("SELECT name FROM table WHERE something IN (?,?,?)")
$db->execute( @parameters );
It's building something like:
$db->prepare("SELECT name FROM table WHERE so
Re: (Score:2)
Re:Actual irony? (Score:4, Funny)
Would this be actual irony, as opposed to Alanis Morrissette irony?
That a song with that name contains no actual examples of irony is ______.
This message brought to you by Deep Metathinking and the Number 12.
Re: (Score:2)
A woman meeting the man of her dreams, and his wife is definitely not ironic, as it's very likely that many women admire the same qualities in men. That becomes a matter of who met whom in what order, and the wife happened to get there first while presenting the qualities that he admired.
T
Re: (Score:3)
Rain on a wedding day isn't ironic...
Agreed.
Irony is rain on the wedding day of a couple of meterologists.
I may be wrong, but I think that coincidence is 2-factor, irony is 3-factor
Re: (Score:2)
I believe that's just sad coincidence, it's missing a third factor.
It would be ironic if she were dropped off the ladder AND her family owned the ladder factory.
Irony be tricky.
Re: (Score:2)
"It's like SQL injectiooooooon, on a module that's designed specifically to help prevent SQL injection attaaaaaaaaaaacks"
It practically writes itself!
Re: (Score:2)
All we have to do is make the algorithm recursive so it fixes sql injection problems in its own code. Simple.
Re:PHP (Score:5, Interesting)
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.
Re: (Score:3)
Re:PHP (Score:4, Informative)
XML would not be a standard SQL construct. Neither the PHP-internal mssql driver nor the microsoft PHP driver supports TVP [stackoverflow.com].
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 [sourceforge.net] (you can declare them using "datatype ARRAY[size]" but postgresql does not enforce array bounds. MySQL does not do array datatypes at all.
Re: (Score:2)
(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.
Re: (Score:3)
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 eff
Re: (Score:2)
my $sql = 'SELECT * FROM foo WHERE bar IN (' .join(',', ('?') x @array) . ')';
Totally hard.
Re:PHP flame (Score:2)
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 [banshee-php.org].
Re: (Score:1)
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...
Re: (Score:2)
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.
Re: (Score:3)
What about Drupal 6? (Score:3)
The story only mentions Drupal 7. Is Drupal 6 or 8 impacted?
Re: (Score:3)
Drupal 6 does not use the affected abstraction layer.
Re: (Score:3)
Gods save us from poorly-designed abstraction layers designed to do things "better".
Re: (Score:1)
Heh heh :)
Re: (Score:2)
Notice they said "poorly-designed abstraction layers" not "all abstraction layers." Oh and FYI, assembly langauge mnemonics are an abstraction layer so your comeback fails even more.
Re: (Score:3)
Re: (Score:2)
Javascript sucks. Perl is perfect!
If only mod_perl weren't such a motherbitch, perl would be perfect.
At this surprises who? (Score:5, Insightful)
php should get a new motto: "Please Hijack our Platform"
Re: (Score:2)
PHP done right [banshee-php.org]. I challenge you to find a security leak.
Re: (Score:1)
We get it. You're not a noob PHP "developer". You're one of those cool dudes who uses a real man's language and get's all the girls! ( and get's modded insightful for it )
I do both php and python, and while I prefer Python, there is nothing out there written in Python ( or any language, to my knowledge ) that comes close to being as efficient as Drupal in terms of time spent getting to launch. And yes that includes Django, which IMO is really only useful for low level APIs. It offers no tools for efficient
Valuable lesson learned (Score:2)
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.
Re: (Score:3)
Now 100% of my projects are in my custom CMS where obfuscation is the rule.
So now instead of many eyes on your CMS, there are only yours? People who keep up with their updates don't really have to worry about this. I used to check my site status page daily, but I noticed that I get notified of all the major Drupal patches by Slashdot, which is handy.
Re: (Score:1)
Well, if you have 250 websites to manage like me, it still prefer my CMS: I decide when to patch my code and update my clients site. I don't want to be dictated by a 'code red'. Also, my updates are 97% based on integration of new components (support for cloudbased storage, etc...) and not because of security issues.
A major factor in all this, is that I use rails: the supporting community has an immense array of helpful tools that help me with deployment, migration (new server) and maintenance.
Re: (Score:1)
That's nonsense. Go look at what eventually happened to HB Gary Federal and how all that started [arstechnica.com], (by using a custom CMS).
Your best bet is to pay close attention to security releases, and be thankful the for the Drupal Security Team which is on top of these issues. For more clarity, read these:
https://www.previousnext.com.au/blog/drupal-732-critical-update-our-response
https://www.acquia.com/blog/learning-hackers-week-after-drupal-sql-injection-announcement
Seriously, compared to the Drupal Security Team whic
WhiteHouse.gov (Score:3, Insightful)
Multiple queries (Score:2)
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?