Heine

Today we released a security announcement about a Webform SQL Injection vulnerability outside of the normal release schedule on Wednesday.

I chose to release today with a minimal fix instead of waiting until January 12th for a combination of reasons:

1. The vulnerability was made public.
2. The injection requires no permissions at all.
3. High impact; easy uid 1 access.
4. No other user interaction required.
5. Webform was under high scrutiny last week due to the Geenstijl shockblog.
6. We received news today that the hole was being actively exploited.

This combination could turn out to be very damaging for a lot of Drupal sites should we have waited longer.

Versions

To clear up any confusion regarding the affected supported branches; only Webform 6.x-3.x is affected. Users of Webform 6.x.3.x should upgrade to Webform 6.x-3.5.

The Webform 6.x-2.x versions are not affected by this vulnerability. As long as you use 6.x-2.8, 6.x-2.9 or 6.x-2.10 you're good. Older versions of the Webform 6.x-2.x branch have different vulnerabilities that were already announced.

Webform for Drupal 5.x and the 7.x betas are not supported by the security team.

Apart from PHP bugs and Denial of Service attacks, there's another reason why calling unserialize on user-supplied data (cookies, hidden form fields) is a bad idea.

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

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.

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:

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:

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

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:

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

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:

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.