Heine

We recently received a report by "ZeroDayScan", about a "Full path disclosure bug in Drupal 6.16".

You can read the story @ http://blog.zerodayscan.com/2010/04/full-path-disclosure-bug-in-drupal-616.html. As my short comment was removed from the post, I have to resort to a blogpost. My apologies for polluting the Planet.

Summary of the issue: If you set error reporting to the default value "Write errors to the log and to the screen", the installation path is displayed on the ...*drumroll*... screen.

Which is of course the point.

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.

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.

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:

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.

When someone mentioned that modx was the new Drupal, I got curious and decided to see for myself.

The cursory exploration got a little more involved when I noticed that, by default, modx doesn't enable any protection against Cross site request forgeries (CSRF). I discovered this by using CSRF to get the administrator password changed. Turns out this is already known since 2008.

After some more digging, I found ticket MODX-206 (registration required), where an HTTP_REFERER check was added as a form of protecting against CSRF.

This option is disabled by default; you need to visit Tools - Configuration :: Site tab to enable the setting Validate HTTP_REFERER headers?. (Note: This can prove to be painful when you run ZoneAlarm, or something else that strips referrers from headers). The setting appears to be documented on a forum post only.

Unfortunately, the HTTP_REFERER check only checks whether the modx site url is part of the referrer. That means that the referrer http://evil.example.com/payload.html?s=http://vulnerable-modx.example.com/ passes the check.

I've spoken with a number of modx developers and they told me a number of 'forms' react to GET requests as well. That means that even when the referrer check is fixed, a modx 1.0.0 site is still vulnerable to CSRF when users are allowed to post URLs on your site as they could post a URL to your own site. If you happen to follow one such URL while being logged in as manager, the referrer checker receives a correct HTTP_REFERER and takes the unintended action.

Until a list of GET-able actions is compiled, it is hard to estimate the impact of this issue.

Beware that malicious users can make it less obvious that you target your own site by using tinyURL or a custom (less obvious) 301 redirector.

A full solution (works with GET, works for people without HTTP_REFERER) would be to add a token to every form and GET request (taking an action), then check those on the actual GET and POST requests.

Due to the way modx 1.0.0 ("Evolution") is build, that is a monumental task and not something the developers are interested in or have time for. They are working hard on the next installment of modx ; Revolution.

Considering the situation with Evolution, I can only advise you to wait until Revolution is released before starting with modx on internet-facing servers.

If you are already using modx 1.0.0, you are in a tight spot. I urge you to deploy and enable the referrer check fix asap after it is released. Do not allow users to post URLs or images on your site (depends on your site configuration) and upgrade to Revolution when it comes out.

If you want, you can try the attached patch for modx 1.0.0.

IMO, and I'm sure in the opinion of the modx developers too, the Evolution code base cannot die quickly enough.