Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Drupal 7 SQL Injection Vulnerability

sektioneins.de

Post reply on HN
Print view View original

31–40 of 83 posts

Re: Drupal 7 SQL Injection Vulnerability

#31

Post by pessimizer »

WoodenChair wrote: post #13

I feel like Hacker News has become home of the "security exploit du jour." There have always been new exploits being found daily, what's changed is the severity and wide reaching nature of said exploits. You might ask, when will we learn? Well, the truth is making secure systems is incredibly hard work and often comes at the price of flexibility/usability/programmer productivity. We know how to do it, it's just not e…

>I feel like Hacker News has become home of the "security exploit du jour."

When wasn't it? Whenever there's a big security advisory that will affect a large percentage of people who browse HN, you see it voted up on HN, explained in detail, and the media using the thread as a source.

Re: Drupal 7 SQL Injection Vulnerability

#33

Post by thejosh »

WoodenChair wrote: post #13

I feel like Hacker News has become home of the "security exploit du jour." There have always been new exploits being found daily, what's changed is the severity and wide reaching nature of said exploits. You might ask, when will we learn? Well, the truth is making secure systems is incredibly hard work and often comes at the price of flexibility/usability/programmer productivity. We know how to do it, it's just not e…

900k+ sites with Drupal, including many government sites. This is a pretty major exploit - any site running unpatched can be shelled.

Re: Drupal 7 SQL Injection Vulnerability

#34

Post by geerlingguy »

jgrahamc wrote: post #9

If you are a paying CloudFlare customer using Drupal please make sure you have the WAF ruleset for Drupal enabled ( https://blog.cloudflare.com/automatic-protection-for-common-... ) as we rolled out automatic protection against this when it was announced.

In addition, if you use Acquia, Pantheon, Platform.sh, or some other hosting providers that directly support Drupal, they may have already at least partially mitigated the attack. But you should still immediately update your code either by upgrade to Drupal 7.32 or by applying the one line patch mentioned elsewhere.

Note that Drupal 6 is not affected (it didn't use PDO, so this parameter parsing functionality doesn't exist).

Re: Drupal 7 SQL Injection Vulnerability

#35

Post by kijin »

meritt wrote: post #27
userbinator wrote: post #25

Drupal uses prepared statements in all its SQL queries. There's this common misconception "just use prepared statements and they'll completely prevent SQL injection" floating around. Good to see (yet another) counterexample of that. Prepared statements and parameters are only strategies that can help, but they don't replace an understanding of where the characters in the query are coming from and how they're being us…

These aren't prepared statements. This wouldn't be an issue if they were actual RDBMS prepared statements. These are the bullshit fake prepared statements that PDO emulates by default to achieve cross-database compatibility to offer things like named-parameters (oracle, postgresql support) for databases that only offer positional parameters (mysql, mssql). It's quite simply shoddy string substitution that's not doing…

PDO's prepared statement "emulation" is ridiculous, and turning it off might have blocked some forms of this vulnerability since it would prevent breaking up one query into many. But fixing PDO wouldn't have entirely prevented this fiasco, either.

No amount of prepared statement kung-fu will save you when the querystring itself contains untrustworthy data. Which is exactly what Drupal is doing here. It puts untrusted, potentially non-integer array keys directly into a querystring. Even if Drupal used a database library that supported proper prepared statements, it would have been owned just as well, only slightly less severely.

It's similar to another, much more common misuse of prepared statements: using untrusted values in the column name.

Still, it's always a good idea to set PDO::ATTR_EMULATE_PREPARES to FALSE as soon as you create any instance of that bloody class.

Re: Drupal 7 SQL Injection Vulnerability

#36

Post by pestaa »

Please note that in this case the prepared statement gave the false sense of security, but is not actually responsible for the vulnerability.

Due to the statement being prepared, all bound parameters are correctly encoded -- not the parameter names themselves though, which Drupal should have sanitized first.

Letting $data through the array_values() call will give you a zero-indexed array, which gives you predictable and safe parameter names.

Re: Drupal 7 SQL Injection Vulnerability

#38

Post by btucker » 

    16. Sep.  2014 - Notified the Drupal devs via security contact form  
    15. Okt.  2014 - Relase of Bugfix by Drupal core Developers
I know it's open source volunteers & all, but that seems like a rather slow reaction to such a critical vulnerability with a simple fix, doesn't it?

Re: Drupal 7 SQL Injection Vulnerability

#39

Post by danielweber »

perlgeek wrote: post #17

IMHO this is the direct result of conflating arrays/list and hashes/dictionaries into a single thing on the programming language level. Sure, careful programming would have avoided that, but if the two concept were fundamentally different types, this bug would be impossible.

The ability to take in arrays as request variables where users don't expect them is a giant headache with PHP.

Re: Drupal 7 SQL Injection Vulnerability

#40

Post by mgkimsal »

thejosh wrote: post #33
WoodenChair wrote: post #13

I feel like Hacker News has become home of the "security exploit du jour." There have always been new exploits being found daily, what's changed is the severity and wide reaching nature of said exploits. You might ask, when will we learn? Well, the truth is making secure systems is incredibly hard work and often comes at the price of flexibility/usability/programmer productivity. We know how to do it, it's just not e…

900k+ sites with Drupal, including many government sites. This is a pretty major exploit - any site running unpatched can be shelled.

Isn't this just a Drupal 7 issue? Still will affect a lot, but I know plenty Drupal installations from that 900k+ figure that are on 5 and 6.
Post reply on HN