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.
Tags: blogs, meta, planet-debian, security 6 comments
Just tried with iceweasel 3.5.3 from experimental. I did not see any images.
Regards.