Steve Kemp's Blog

Blog Update

I've just updated the home-grown javascript I was using upon this blog to be jQuery powered.

This post is a test.

I'll need to check but I believe I'm almost 100% jQuery-powered now.

AJAX Proxies

It is a well-known fact that AJAX requests are only allowed to be made to the server the javascript was loaded from. The so-called same-origin security restriction.

To pull content from other sites users are often encouraged to write a simple proxy:

• http://example.com/ serves Javascript & HTML.
• http://example.com/proxy/http://example.com allows arbitrary fetching.

Simples? No. Too many people write simple proxies which use PHP's curl function, or something similar, with little restriction on either the protocol or the destination of the requested resource.

Consider the following requests:

• http://example.com/proxy.php?url=/etc/passwd
• http://example.com/proxy.php?url=file:///etc/passwd

If you're using some form of Javascript/AJAX proxy make sure you test for this. (ObRandom: Searching google for inurl:"proxy.php?url=http:" shows this is a real problem. l33t.)

ObQuote: "You're asking me out? That's so cute! What's your name again? " - 10 things I hate about you.

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:

• http://www.steve.org.uk/Hacks/xss-img-test.html

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.

It seems the IMAP client crash I accidentally discovered in Thunderbird/Icedove was already known.

My report is a duplicate of a bug which was previously reported in 2007. Oops.

ObFilm: The Lost Boys

Recently I mentioned I'd been hacking about with a simple IMAP server.

Yesterday I was working on it some more, because the message store I've been testing against contains about 8 million messages and the damn thing is too slow.

During the course of some tweaking I discovered something interesting, every time a specific IMAP client connected to my server it crashed...

I spent a while fiddling around with backtraces and suchlike, but the upshot is I'm still not sure where the client crashes, but I've mailed some details to a few people to see if we can get it narrowed down.

I guess this counts as an accidental security issue. I wonder if I'll be able to collect a bounty? (Not that I'm bitter about past bounty-worthy reports being ignored ;)

Anyway interesting times, when I least expected them.

Mostly this post is being made to test a new release of the chronicle blog compiler - which now allows gravitars and has improved display of comments as demonstrated here.

ObFilm: Rambo First Blood Part II

Last week I resigned from my position as member of the Debian Security Team.

Historically several Debian teams have had members inactive for months and years at a time, and I'd rather be removed of my own volition than end up listed but inactive like that.

It's been a pleasure working with all members of the team, past and current (especially Joey), and who knows I might return in the future.

If you're interested in security work then getting involved isn't difficult. It just takes time, patience, and practise.

ObFilm: The Goonies

meta-hacking

I've had a lot of fun over the past few years detecting and fixing XSS attacks - a few months ago compromising several thousand user-accounts belonging to a particular niche social networking site and then more recently experimenting with XSS issues upon a popular software developer's advocate blog.

One thing I've been wondering about recently is meta-XSS attacks.

Consider the LKML (linux kernel mailing list). This list receives lots of long patches, submitted by email, which are copied verbatum to various sites. For example if I mailed an interesting patch to LKML chances are it would get posted to:

• LWN
• KernelTrap
• ...

(Obviously the challenge here is to make a patch sufficiently interesting that it received more than usual coverage.)

Do each of those sites HTML-encode patches? In general they do, certainly the ones I looked at had code like this:

#include <linux.h>
...
...

But I'm certain that not all sites do so. I'm also pretty sure there are interesting avenues to explore here, and the general idea of indirectly attacking a specific target is ripe for exploration.

Anyway I'm probably not the person to go playing in the field these days; I don't have the time. But it is certainly interesting to think about.

ObFilm: Dirty Harry

In response to the comments left on my previous entry about executable configuration files I've changed the way that tscreen works.

There is still support for using an arbitrary shell script or binary as a configuration file, but you must be explicit to enable it:

#
#  Load the dynamic section, if it exists.
#
if -x ~/.tscreen.dynamic  'source ~/.tscreen.dynamic|'

The change here is the trailing "|" on the argument to the source command:

source ~/foo/bar

Opens ~/foo/bar and parses the contents. (Assuming it exists.)

source ~/bin/blah|

Executes ~/bin/blah and parses the output. (Assuming it exists)

I still see no security risk with the previous setup, but I'm happy to apply a little misdirection if that makes people feel better.

ObFilm: Ghostbusters

I wasn't going to comment on the recent openssl security update, because too many people have already done so.

Personally I thought that Aigars Mahinovs made the best writeup I've seen so far.

However I would like to say that having 20+ people all mailing security[at]debian.org to say the webpage we referenced in the security advisory is currently blank is not useful, or ask for details already released in the advisory they replied to, or ask for even more details is not so much fun.

Having people immediately start mailing questions like "Huh? What can I do" is only natural, but you can't expect a response when things are as hectic as they have been recently. Ideally people would sit on their hands and bite their tongues. Realistically that isn't going to happen, and realistically this post will make no difference either...

Had the issue not leaked to unstable so quickly (and inappropriately IMHO) then we'd have had a little more time. But once an issue is reported you need to coordinate with other distributions, and etc. Handling something as severe as this is not fun, and random mails from users are a distraction, and a resource-hog.

I should say I was not in any way involved in the discovery, the reporting, the preparation of the fix(es), or the releasing of the update. I knew it was coming, but everybody else seemed to have it well in hand. When there are mails going back and forth for 5+ days with ever-growing Cc: lists, and mailing lists being involved I figure one more cook wouldn't be useful.

So in conclusion:

a. Bad hole.

b. Fixing this will take years, probably.

c. 50+ mails to the security team within an hour of the advisory going public complaining of missing information is not helpful, not useful, and quite irritating. (Albeit understandable).

d. People who don't know the details of an attack, or issue, shouldn't speculate and start panic, fear, and confusion. Esp. when details are a little vague.

e. I still like pies.

Once again thanks to everybody who was involved and put in an insane amount of work. Yes this is only the start - our users have to suffer the pain of regenerating everything - but we did good.

Really. Debian did good.

It might not look like it right now, but it could have been so much worse, and Debian did do good.

ObQuote: X-Men: The Last Stand

If you upload a new package to the Debian archive which contains a setuid or setgid binary please please ask for a security audit, or carry out one yourself.

I certainly accept that the security audit project webpages are not terribly current, and the mailing list is essentially dead, but there are people, such as myself, who would gladly look at your package. All you have to do is ask.

When I see two packages in testing with trivialy obvious security bugs it just makes me wonder why we bother.

• tss
  • tss: local root exploit
  • tss: Allows reading arbitary files
• acon
  • #475733 acon: local root exploit

I'm going to take this chance to restate my hardline position on package maintainence - even though it might not be directly applicable - If you cannot program/debug/handle the language a package is developed in you shouldn't maintain it.

Too often I've seen signs of this; somebody maintaining a C-based program but unable to program in C. Why?

I wonder if we could have a policy / guideline that any new setuid/setgid application must have at least two maintainers, or a documented audit prior to acceptance? Hard to manage but I think it would be useful even if it didn't catch everything. Some bugs such as #475747 (lovely number!) are trivial to discover.

ObQuote: Dangerous Liaisons

On Tuesday I released a new version of rinse which now supports Fedora Core 8.

On Wednesday I rebuilt xen-unstable several times, and reported a vaguely security relevant issue against the Exaile music player. I flagged that as important, but I'm not really sure how important it should be. True it works. True it requires DNS takeover, or similar, to become a practical attack, but .. serious or not?

Today I'm wondering about "hiding" messages in debian/changelog files. Each changelog entry includes the time & date of the new revision. I tend to pick the last two digits of the timestamp pretty much as random. (ie. the hours and minutes are always correct, but the seconds is a random value).

Given two digits which may be manipulated in the range 0-59 I'm sure a few small messages could be inserted into a package. But the effort would be high. (Hmmm timezone offset too?)

And that concludes todays entry.

I made a new release of the Chronicle blog compiler the other day, which seems to be getting a suprising number of downloads from my apt repository.

The apt repository will be updated shortly to drop support for Sarge, since in practise I've not uploaded new things there for a while.

In other news I made some new code for the Debian Administration website! The site now has the notion of a "read-only" state. This state forbids new articles from being posted, new votes being cast, and new comments being posted.

The read-only state is mostly designed for emergencies, and for admin work upon the host system (such as when I'm tweaking the newly installed search engine).

In more coding news I've been updating the xen-shell a little recently, so it will shortly have the ability to checksum the filesystem of Xen guests - and later validate them. This isn't a great security feature because it assumes you trust dom0 - and more importantly to checksum files your guest must be shutdown.

However as a small feature I believe the suggestion was an interesting one.

Finally I've been thinking about system exploitation via temporary file abuse. There are a couple of cases that are common:

• Creation of an arbitrary (writeable) file upon a host.
• Creation of an arbitrary (non-writable) file upon a host.
• Truncation of an existing file upon a host.

Exploiting the first to go from user to root access is trivial. But how would you exploit the last two?

Denial Of Service attacks are trivial via the creation/truncation of /etc/nologin, /etc/shadow, (or even /boot/grub/menu.lst! But gaining privileges? I can't quite see how.

Comments welcome!

Curse you Debian! Your programs are too secure...

So I was looking over some setgid binaries last night, seeing if there were any obvious security bugs.

Up popped omega-rpg - a fun game I've recently been playing. Unfortunately it is mostly OK:

• The insecure support for save-game-compression is disabled for Debian.
• The use of environmental variables is safe.
• The use of low-memory detection is disabled on non-MSDOS systems.
• The console-based input doesn't succumb to badness if you resize your terminal to allow >80 character input.

The only thing that I can is persuade the game to die with a SIGSEG if I manaully edit a save-game file, then load it. I'm sure with care and patience it could be coerced into running shellcode.

In theory this is a security hole. In practise it is hard to take seriously!

On the other hand I'm not convinced the game should be setgid(games)..