About Archive Tags RSS Feed


Hack the planet!

22 September 2009 21:50

Recently I was viewing Planet Debian and there was an entry present which was horribly mangled - although the original post seemed to be fine.

It seemed obvious to me that that some of the filtering which the planet software had applied to the original entry had caused it to become broken, malformed, or otherwise corrupted. That made me wonder what attacks could be performed against the planet aggregator software used on Planet Debian.

Originally Planet Debian was produced using the planet software.

This was later replaced with the actively developed planet-venus software instead.

(The planet package has now been removed from Debian unstable.)

Planet, and the Venus project which forked from it, do a great job at scrutinising their input and removing malicious content. So my only hope was to stumble across something they had missed. Eventually I discovered the (different) filtering applied by the two feed aggregators missed the same malicious input - an image with a src parameter including javascript like this:

<img src="javascript:alert(1)">

When that markup is viewed by some browsers it will result in the execution of javascript. In short it is a valid XSS attack which the aggregating software didn't remove, protect against, or filter correctly.

In fairness it seems most of the browsers I tested didn't actually alert when viewing that code - but as a notable exception Opera does.

I placed a demo online to test different browsers:

If your browser executes the code there, and it isn't Opera, then please do let me know!

The XSS testing of planets

Rather than produce a lot of malicious input feeds I constructed and verified my attack entirely off line.

How? Well the planet distribution includes a small test suite, which saved me a great deal of time, and later allowed me to verify my fix. Test suites are good things.

The testing framework allows you to run tiny snippets of code such as this:

# ensure onblur is removed:
HTML( "<img src=\"foo.png\" onblur=\"alert(1);\" />",
      "<img src=\"foo.png\" />" );;

Here we give two parameters to the HTML function, one of which is the input string, and the other is the expected output string - if the sanitization doesn't produce the string given as the expected result an error is raised. (The test above is clearly designed to ensure that the onblur attribute and its value is removed.)

This was how I verified initially that the SRC attribute wasn't checked for malicious content and removed as I expected it to be.

Later I verified this by editing my blog's RSS feed to include a malicious, but harmless, extra section. This was then shown upon the Planet Debian output site for about 12 hours.

During the twelve hour window in which the exploit was "live" I received numerous hits. Here's a couple of log entries (IP + referer + user-agent):

xx.xx.106.146 "http://planet.debian.org/" "Opera/9.80
xx.xx.74.192  "http://planet.debian.org/" "Opera/9.80
xx.xx.82.143  "http://planet.debian.org/" "Opera/9.80
xx.xx.64.150  "http://planet.debian.org/" "Opera/9.80
xx.xx.20.18   "http://planet.debian.net/" "Opera/9.63
xx.xx.42.61   "-"                         "gnome-vfs/2.16.3

The Opera hits were to be expected from my previous browser testing, but I'm still not sure why hits were with from User-Agents identifying themselves as gnome-vfs/n.n.n. Enlightenment would be rewarding.

In conclusion the incomplete escaping of input by Planet/Venus was allocated the identifier CVE-2009-2937, and will be fixed by a point release.

There are a lot of planets out there - even I have one: Pluto - so we'll hope Opera is a rare exception.

(Pluto isn't a planet? I guess thats why I call my planet a special planet ;)

ObFilm: Hackers.



Comments on this entry

icon Sridhar M.A. at 16:23 on 22 September 2009

Just tried with iceweasel 3.5.3 from experimental. I did not see any images.


icon Diego E. “Flameeyes” Pettenò at 17:43 on 22 September 2009

I think the gnome-vfs hit might actually be some gnome-vfs based news reader, it's the only thing that would make sense…

Although to be honest, I hate software that only provides the name of the library… at least I'm sure liferea should announce itself properly, and specto does not use gnome-vfs anyway, not sure what else is available.

icon sno at 18:08 on 22 September 2009

opera had popups here, firefox did not (even after enabling js)

icon Steve Kemp at 18:10 on 22 September 2009

That matches my expectations:

  • Opera: Vulnerable.
  • Mozilla: Not vulnerable.

For what its worth Epiphany seemed safe too. But I'm sure there are some more unusual browsers that might be available to attack..

icon Firefalcon at 23:35 on 22 September 2009

Under my Windows XP virtual test machine:

Google Chrome 2.0.472.43 is not affected, although displays a broken image symbol (ditto for once I had upgraded).

Like Chrome, Safari (for Windows, 4.03 531.9.1) was unaffected but showed a broken image.

Confirmed Opera 10.00 (Build 1750) as vulnerable.

As per your expectations, Firefox 3.0.14 was not vulnerable.

Internet Explorer 8 was also not vulnerable.

I also ran it through BrowserShots.org ( http://browsershots.org/http://www.steve.org.uk/Hacks/xss-img-test.html ) and it seems IE 5.5 and 6 are vulnerable too, and shows the Opera's vulnerability appears to goes back to at least version 7.54.

icon Opoho at 09:58 on 23 September 2009

Testing with IE7 at work gave me just a broken image symbol (no alert box).