FYI: Out of band release & branch

I can't see it on the project page - so if anyone else is looking - it's here http://drupal.org/node/7404/release

At the moment (11:14 GMT), my "available updates" page is still listing 3.4 as the latest and, even though I've updated to 3.5 via a "cvs up", Available Updates still considers 3.5 as "insecure". I'm assuming this is some kind of caching issue on drupal.org?

Same issue here... Drupal.org states Webform 3.5 as 'recommended release' for D6, but the update status page doesn't know 3.5 exists and flags it as a revoked version or something. What kind of caching does http://updates.drupal.org/release-history use, and should it have caching at all, or is something else going wrong?

Built the update-URL manually, and that states 3.5 as security update btw: http://updates.drupal.org/release-history/webform/6.x

Its probably because Heine has released this as a patch as the maintainer is away. Could do with making it obvious on the project page, esp if this is in the wild.

The update XML does mention the 3.5 version, but is marked 'unpublished':

<release>
 <name>webform 6.x-3.5</name>
 <version>6.x-3.5</version>
 <tag>DRUPAL-6--3-5</tag>
 <version_major>3</version_major>
 <version_patch>5</version_patch>
 <status>unpublished</status>
 <date>1294652806</date>

So, I am assuming that even though it shows as being revoked, that loading 6.x-3.5 is the preferred security update???

yes

Thanks for sorting this so fast Heine. I'm also getting the same "module revoked" message with 6.x-3.5.

Will we need to carry out any further action or is it something that will be resolved on Drupal.org when the maintainer gets back?

Does anyone have an example of a successful attack? i can see the vector, but i experienced some oddities last night on a client site and would like to see some signatures i can verify against - e.g. if this attack has been used on a site, is anyone willing to share the symptoms?

Thanks,

I just ran updates for a second time and the revoked notice went away!

I can also confirm that a "force check" on available updates now accepts 3.5 as the latest release.

It looks like the issue was with webform_get_submissions where the submission ID wasn't being passed into the SQL using placeholders, but instead was being embedded directly into the SQL.

However, unless I've missed something in my "quick scan" (using grep to find instances of that functions usage) shows that it would have been very hard to abuse.

That function only appears to be used in cases where, say, a node ID is loaded and then you pass the node NID into the funciton. There is only one case where the provided parameter isn't $node->nid or $user->uid, and that's in a result clearing function - however to have gotten to the point where that function RUNS means that the provided $nid would have had to be numeric anyway and passed other access checks.

Obviously discussing EXACTLY how to abuse a site with this issue would be inappropriate (as its essentially a tutorial for script kiddies) but I would be interested to know if there are any cases I have missed where this function could realistically be abused... I dont understand how the "in the wild" attack happened...

I don't disagree with not posting exploit code, but a conversation about how the exploit could work and what symptoms we might see would be more than useful, esp where client sites can't be updated for one reason or another.

I have 6 webform submissions from yesterday on a webform that hasnt been used since the summer, all with missing data. So can i assume the attacks were bots? I saw a big cpu spike around the same time...will report if i find anything further.

oh dear... I have 400 new users with spam email addresses... I guess thats the symptom.

I had three domains that were using the vulnerable version, 2 of which appear to have been hit. Both had around 40 users added from around saturday through 10am this morning (monday).

Luckily the databases all have different passwords, and neither site allowed authenticated users to do anything and no permissions had been changed. I dread to think what may have happened if either site was running a forum module etc.

In case anyone is struggling with lots of 'legalroids' and 'xxx_love_you_long_time' style users:
UPDATE `users` set status=0 where uid !=1;
Will disable everyone except admin until you've sorted it.

Does anyone have an example of a successful attack? i can see the vector, but i experienced some oddities last night on a client site and would like to see some signatures i can verify against - e.g. if this attack has been used on a site, is anyone willing to share the symptoms?

I believe that this SQL injection is much more dangerous to users using pgSQL instead of MySQL. MySQL in PHP does not allow multiple queries to be executed in the same statement, but pgSQL does. This makes pgSQL users much more susceptible to exploitable attacks. MySQL users may still be vulnerable to access bypass vulnerabilities to view and/or edit any submission on the site, making this still very important to update even for all users.

This is the difficult thing about Security discussions. It's almost impossible to discuss this specific vulnerability without essentially writing a how-to for beginner hackers. But on the flip side, how are people supposed to learn WHY they should use the Database API's provided by Drupal if they can't be shown what will happen if they don't use them?

Telling someone "if you use this then you're secure" isn't the same as showing them how someone can become an admin on their site if they don't use the db_placeholders function when embedding several node ID's into a query.

I personally understand the concepts of SQL injection and I've seen basic demo's - Is it worth having some pages on Drupal.org explaining to developers how *NOT* using the DB-API causes issues?

Ahh that's a really nice explanation - thank you for sharing Heine, much appreciated. That should go a long way to helping people understand the issue.