Drupal 7 SQL Injection Vulnerability • Hacker News Board

Re: Drupal 7 SQL Injection Vulnerability

#51

Post by meowface » Thu, Oct 16, 2014, 1:16 PM UTC

mappu wrote: post #15

philo23 wrote: post #10

Earlier quoted context omitted.

It appears to be a pretty serious issue. The SQL injection alone is bad but the ability to run basically any PHP code through callbacks makes the problem that much worse.

SQL injection alone is often enough to get you RCE if your MySQL account has FILE permissions enabled (often true). Something like `SELECT "<?php eval($_GET['x'])" INTO OUTFILE /srv/www/backdoor.php`.

>(often true)

I don't think it's that often. By default, a new MySQL user will not have FILE privileges granted.

Most of the time you see this due to the developer being lazy and just using the "root" MySQL user.

Re: Drupal 7 SQL Injection Vulnerability

#52

Post by dageshi » Thu, Oct 16, 2014, 1:17 PM UTC

thathonkey wrote: post #44

dageshi wrote: post #21

For those who don't want to do a full core update, you can apply a one line patch by the looks of it. http://www.reddit.com/r/drupal/comments/2jbuiz/drupal_732_fi...

7.32 is a one line change btw, so the patch is same difference.

You're right, but whenever I hear the words "Core Update" I usually think "Testing". For something this serious just getting that vulnerability patched asap seems like a good idea, especially if you look after a lot of drupal sites.

Re: Drupal 7 SQL Injection Vulnerability

#53

Post by eli » Thu, Oct 16, 2014, 1:25 PM UTC

taspeotis wrote: post #49

meritt wrote: post #27

Earlier quoted context omitted.

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…

> databases that only offer positional parameters (mysql, mssql). Something between PHP and MSSQL must not support named parameters, because MSSQL supports them just fine.

So does MySQL, actually. They are just allegedly slow (though I've never benchmarked and I wouldn't be surprised if that's no longer the case).

Re: Drupal 7 SQL Injection Vulnerability

#54

Post by gabriel-aszalos » Thu, Oct 16, 2014, 1:27 PM UTC

GitHub OAuth results in: {"type":"Error","msg":"Hostname/IP doesn't match certificate's altnames"}

Re: Drupal 7 SQL Injection Vulnerability

#55

Post by vezzy-fnord » Thu, Oct 16, 2014, 1:36 PM UTC

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…

There have always been new exploits being found daily, what's changed is the severity and wide reaching nature of said exploits.

Actually, what's changed is a tendency to now give scary names to exploits and to insist on the importance of "branding and marketing" them to increase end user awareness, or something.

It's gotten a little farcical, I think. It's also lead to a lot of ignorant impressions about free software, as of recent. In spite of the fact that everything is business as usual.

Re: Drupal 7 SQL Injection Vulnerability

#56

Post by pearjuice » Thu, Oct 16, 2014, 1:41 PM UTC

TacticalMalice wrote: post #18

anonfunction wrote: post #11

> Full SQL injection, which results in total control and code execution of Website. Well that doesn't sound good. Drupal.org itself is still running[1] on the unpatched version 7.3.1 which sends a message of how likely sites are to be updated. [1] https://www.drupal.org/CHANGELOG.txt

Drupal.org is patched and has been for weeks.

That's impressive given the exploit is a day old.

Re: Drupal 7 SQL Injection Vulnerability

#57

Post by pearjuice » Thu, Oct 16, 2014, 1:43 PM UTC

Google searching for "Powered by Drupal" delivers quite a substantial amount of high profile websites. Either as portfolio cases or directly referenced to in website footers. I don't know who will be faster; system administrators patching the bunch or people with malicious intentions writing automated tools to compromise hundreds of sites per second.

Re: Drupal 7 SQL Injection Vulnerability

#58

Post by TacticalMalice » Thu, Oct 16, 2014, 1:46 PM UTC

pearjuice wrote: post #56

TacticalMalice wrote: post #18

Earlier quoted context omitted.

Drupal.org is patched and has been for weeks.

That's impressive given the exploit is a day old.

Drupal.org was a qa testcase for the patch.

Re: Drupal 7 SQL Injection Vulnerability

#59

Post by antsar » Thu, Oct 16, 2014, 1:56 PM UTC

pearjuice wrote: post #56

TacticalMalice wrote: post #18

Earlier quoted context omitted.

Drupal.org is patched and has been for weeks.

That's impressive given the exploit is a day old.

FTFA:

> Disclosure Timeline:

> 16. Sep. 2014 - Notified the Drupal devs via security contact form

> 15. Okt. 2014 - Relase of Bugfix by Drupal core Developers

Re: Drupal 7 SQL Injection Vulnerability

#60

Post by jwineinger » Thu, Oct 16, 2014, 1:58 PM UTC

anonfunction wrote: post #23

The patch is only one line[1], so if you're scared to update Drupal for fear of breaking things you can just patch the vulnerable part. In this file: includes/database/database.inc Replace line 739: foreach ($data as $i => $value) { With the patched code: foreach (array_values($data) as $i => $value) { [1] https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patc...

So is that the full patch or is there a validation test included somewhere else?