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

71–80 of 83 posts

Re: Drupal 7 SQL Injection Vulnerability

#71

Post by ge0 »

jwineinger wrote: post #60
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?

There is also a test http://cgit.drupalcode.org/drupal/commit/?h=7.x&id=449c70287...

Re: Drupal 7 SQL Injection Vulnerability

#72

Post by kbenson »

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...

When I wrote PHP, I never felt comfortable with associative arrays and sequential arrays being almost indistinguishable. Part of that is my Perl heritage, I'm sure, but the slight cognitive load it reduced in choosing your data structure always seemed vastly dwarfed by the extra complexity of umpteen different functions that work on arrays in different ways and the confusion it can cause when you didn't receive exactly what you were expecting and ended up with non-numerical keys when you expected numerical ones or vice-versa (as in this case).

I guess it's just another example of the Waterbed Theory[1].

1: http://en.wikipedia.org/wiki/Waterbed_theory

Re: Drupal 7 SQL Injection Vulnerability

#73

Post by DCoder »

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.

Actually, Microsoft's SQLSRV PDO driver supports named parameters.

Re: Drupal 7 SQL Injection Vulnerability

#74

Post by zgwortz »

So, while patching our sites for this, we found one which apparently had already been patched. This was highly suspicious, especially since the file mod date is listed as approximately 9 hours ago when nobody was using the system and no login is registered for it, so we've been investigating. The only thing we've found so far is another file which was apparently created at the same exact time as the update:

modules/toolbar/pfmm.php

…which doesn't actually exist in the toolbar module (or anywhere else I can find). The contents of that look like an attempt to use some kind of exploit:

Not quite sure what that means, but we're still looking into it.

Re: Drupal 7 SQL Injection Vulnerability

#75

Post by zgwortz »

zgwortz wrote: post #74

So, while patching our sites for this, we found one which apparently had already been patched. This was highly suspicious, especially since the file mod date is listed as approximately 9 hours ago when nobody was using the system and no login is registered for it, so we've been investigating. The only thing we've found so far is another file which was apparently created at the same exact time as the update: modules/t…

I should add that the file was created by www-data:www-data, which for us stands out like a sore thumb as something created by a web page and NOT a user - our build process usually leaves it with a different user as the owner.

Re: Drupal 7 SQL Injection Vulnerability

#76

Post by Ded7xSEoPKYNsDd »

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`.

This would also depend on hilariously bad permissions on /srv/www that allow the mysql user to create files there.

Re: Drupal 7 SQL Injection Vulnerability

#77

Post by snowwrestler »

zgwortz wrote: post #74

So, while patching our sites for this, we found one which apparently had already been patched. This was highly suspicious, especially since the file mod date is listed as approximately 9 hours ago when nobody was using the system and no login is registered for it, so we've been investigating. The only thing we've found so far is another file which was apparently created at the same exact time as the update: modules/t…

Look at your server logs. Look at the timestamps around the file create date, and grep the logs for that path. You might be able to see a request creating that file, or calling it (neither is good...)

Re: Drupal 7 SQL Injection Vulnerability

#78

Post by mixologic »

pearjuice wrote: post #57

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.

The latter.

Re: Drupal 7 SQL Injection Vulnerability

#79

Post by zgwortz »

snowwrestler wrote: post #77
zgwortz wrote: post #74

So, while patching our sites for this, we found one which apparently had already been patched. This was highly suspicious, especially since the file mod date is listed as approximately 9 hours ago when nobody was using the system and no login is registered for it, so we've been investigating. The only thing we've found so far is another file which was apparently created at the same exact time as the update: modules/t…

Look at your server logs. Look at the timestamps around the file create date, and grep the logs for that path. You might be able to see a request creating that file, or calling it (neither is good...)

Already done. They're using the SQL injection to create a new page entry in the menu_router table whose access function was file_put_contents(). They then call this new page (in our case, they called it "nqabio") to write the file(s), and then called the pfmm.php.

Unfortunately, that code actually is taking PHP function calls from the cookies passed in with the request, and we didn't have cookie logging enabled, so we have no way of figuring out what that actually did. I suspect the Kcqf3 cookie is a decoder or decryption function, but the Kcqf2 function name is a mystery, and the Kcqf1 parameter could be anything.

Re: Drupal 7 SQL Injection Vulnerability

#80

Post by chx »

outlandish-josh wrote: post #70
ceejayoz wrote: post #66

Earlier quoted context omitted.

I really don't think that is a valid excuse for taking a month to make a one-line critical security patch.

The vulnerability has been there for four years. It's critical, but not widely exploited. As soon as you release an update, the exploits will be found and weaponized. It's 24 hours later and we're already clocking scripted attacks. Coordinating a flawless release by a) not doing it during a major distraction event (DrupalCon) and b) allowing an embargo period for people within the security community to prepare is MUC…

Six years. It was committed in 2008 december.
Post reply on HN