Attack Surface

I allege that

1. Any program that is capable of parsing untrusted content is vulnerable to exploitation by malicious entities.
   
2. Programs which parse binary file contents are particularly vulnerable due to the tendency of such formats to use offset pointers and other values which the parsers assume are valid -but which "fuzzing" can be used to discover new exploits.
   
3. Programs that treat the data as containing executable content -even within a sandbox- are vulnerable to any exploit that permits code to escape the sandbox, or simply to Denial of Service attacks in which resources in the sandbox such as memory, CPU time and network bandwidth are consumed.
   
4. Recent incidents involving the generation of false certificates for popular web sites have shown that signed web sites and signed content cannot be consistently trusted.
   
5. Any program that can process content downloaded by an HTTP client application is capable of parsing untrusted content, and so vulnerable to exploitation.
   
6. Any program that can process content received in the payload of email messages is capable of parsing untrusted content, and so vulnerable to exploitation.
   
7. Any program that can process delivered in untrusted physical media is capable of parsing untrusted content, and so vulnerable to exploitation.
   

The last of these items concerns me today. The Stuxnet worm has shown how a well-engineered piece of malware can propagate between windows machines, and across an airgap from windows machines to SCADA infrastructure by way of USB infection. The Sony Rootkit Scandal showed that even large business were willing to use this to sneak on anti-copying features on what pretended to be a music CD.

A key conclusion from the CERT advisory on the Sony Incident was Disable automatically running CD-ROMs by editing the registry to change the Autorun value to 0 (zero) as described in Microsoft Article 155217.


I've long disabled autorun on windows boxes, and I also remember testing a long time ago whether or not you could autorun a CD while the screen was locked. Answer: no. Windows waits until the screen is unlocked before an autorun application is executed. This provides some defence against malicious CDs, though not as much as disabling autorun completely.


I don't worry too much about windows security these days because my main machines are Linux boxes, which keep themselves up to date with apt-get update. This keeps browsers, flash, JVMs, OpenOffice current, which reduces their vulnerability. I also keep an eye on the SANS newsfeed to see if there are any 0-day exploits out, and take proactive action if anything gets out into the wild that we are at risk from. I've stopped fielding service requests from family members saying "there is something on my machine -can you clean it up". If I am asked, my response is "I will reformat your HDD and install ubuntu on it". FWIW, I have done this for one relative and it works really well.


I am confident that I do keep my machines locked down, and know that the primary vulnerability on an Linux system on which I do open source development is that I implicitly have to trust everyone who has commit rights to every application that I use on it.


If there is one issue I have with Linux is that it is over-paranoid. For example, once the screen is locked I can't suspend the system. This means that I can't suspend the laptop until I unlock it and hit the suspend button. Somewhere on launchpad there was a bugrep about that, but people who looked after servers were saying "no!", despite the fact that if I had physical access to the power button, it would be only four-seconds away from a hard power off, and then, unless the system had the CD-ROM, USB and PXE boot disabled, one to two minutes from being my box. It's annoying but a sign that security is taken over-seriously.


Imagine my surprise then, last week, on inserting a CD-ROM from an external source when suddenly the system started grinding away, with a tiny thumbnail of each PDF image appearing one after the other. For that to happen the desktop had to have scanned through the list of files, handed each PDF file off to some parser and got a 64x64 graphic back. It wasn't the wasted effort that concerned me -it was the way it did this without me even asking.


I did some research and discovered an article on the topic. Essentially the Linux desktop standard allows for autostart.sh files to be executed on mounting a media device. The the thumbnailing is something else: nautilus defaults to doing this for local files -and views all files on mounted local media as "local", rather than "untrusted content on an untrusted filesystem". Given that exploits have been found in the thumbnailing code, having Nautilus thumbnail files on an external device is insane.


The best bit: this happens even while the desktop is locked.


There I am, regularly saying rude words because I thought I'd suspended my laptop, but as the screen was locked it's just stayed powered up, slowly killing the battery and/or overheading in a bag. I accepted this inconvenience as I thought it was a security feature for my own good. It turns out that it was irrelevant as all you needed to do was plug in a USB stick with a any .dvi, .png or .pdf file designed to exploit some security hole and my box is 0wned. Which, if done while I am logged in, offers access to the encrypted bits of the box.

There is a workaround -disable all thumbnailing even of local content, as well as the usual "do nothing" action on handling media insertions. I've done that everywhere. Yet what annoys me is this: what were the dev team thinking. On the one hand there is the power management group saying "we won't let people suspend while the desktop is locked for security reasons", while some other people are thinking "let's generate thumbnails whenever new media is inserted". The strength of OSS is that anyone can contribute. The weakness: a lot of them aren't devious enough to recognise what they think of a feature is someone else's route of access to your systems


[Photo: Park Street]