other day Peter was talking about the ActiveX
Control of Ultimate Destruction — a hostile control which, the moment it is loaded
immediately formats your hard disk. "urn:schemas-microsoft-com:office:office" />The
aim of the ACoUD is to do “as much damage as possible in a short amount of time”.
Peter’s not the only one who’s kept up at night worrying about this stuff. Last
night I couldn’t sleep because I was thinking about how that characterization of the
ACoUD really isn’t bad enough. If this
is going to be the ULTIMATE in destruction, let’s think about just how evil we can
the purposes of this discussion, let’s not care about how the evil code gets on your
machine. Perhaps you download and trust
a malicious ActiveX control. Perhaps
a worm takes advantage of a buffer overrun in the operating system. Perhaps
you got an email virus, or ran a bad macro, or whatever. Let’s
just call all those things malware. Furthermore,
let’s assume that all attempts to stop the malware from running — like never logging
in as administrator, etc, — have failed and that the
malware has elevated its privilege to administrator. Let’s
assume that the malware author is brilliant and
has unlimited time to craft something incredibly
devious. Remember, we’re going for
the ultimate here.
the worst I could come up with:
when the malware is run, first it waits until some point when no one is using the
When the coast is clear, it compresses and backs up the entire hard disk.
It then installs a minimal linux kernel on the box along with a cleverly written Windows
The state of the emulator is set up to exactly mimic the state of the machine as it
was before the attack.
The linux boot sequence is rewritten to exactly resemble the Windows boot sequence,
except that of course what is really happening is that linux is loading a windows
emulator during the boot.
net result: you are not even running Windows
anymore so nothing is trustworthy. ns = "urn:schemas-microsoft-com:office:smarttags" />The
emulator could be logging every keystroke, sending your files to
, whatever the emulator writer wants. The
emulator could be reporting that no, there is no linux boot partition on this disk! You
don’t own that box anymore. The chain
of trust has been broken.
could you detect this attack? Since you’re
not running Windows, you can’t assume that the operating system will report anything about
the machine correctly. You’d have to
boot off of trustworthy media and run utility programs to examine the real state of
could you prevent this ultimate attack? Remember,
we’re assuming that all the usual good stuff has failed, like keeping up-to-date with
patches, not running as administrator, maintaining firewalls, not opening suspicious
email attachments, and so on. What is
the final line of defense against this sort of ultimate malware? Really
the only line of defense that remains is the hardware. To
solve this problem the chain of trust needs to be rooted in the hardware, so that
when the machine boots it can tell you whether you are loading code that has been
signed by a trusted authority or not. The
possibility of constructing such chips has met with considerable controversy over
the last few years, and it remains to be seen whether they are technically and economically
the point is that though this is in many ways a ridiculous “overkill” attack, it is
in principle possible. This is why trustworthy computing is so incredibly important. At
the very least, you need to have confidence that when you boot up your machine, you
are actually running the operating system that you installed!
was thinking about all of this last night because of the recent successful attack
against Valve, a local software company that made the popular video game “Half Life”. I
don’t know the exact details — and probably no one does except for the attackers
who perpetrated the attack — but what seems likely is that attackers exploited a
known vulnerability in Outlook, and a high-ranking Valve employee was vulnerable to
the attack. The malware installed a key
press logger, and from that point, it was pretty much game over, so to speak. By
monitoring key presses they’d quickly learn all kinds of details such as the administrator
passwords to other machines, compromise them, and eventually manage to “own” as much
of the network as possible. The attackers
didn’t have to emulate all of Windows, they just had to tweak it a tiny bit by installing
a key logger.
fact that this underscores the importance of keeping up to date on patches is not
particularly relevant, and I do not ever want to blame the victim for failing to patch
a machine. The important point which
this illustrates is that there is a spectrum of malware out there. Consider
the Blaster worm, which simply tries to cause as much havoc as possible and spread
as fast as possible — that thing wasn’t targeted against anyone in particular, and
though it was very costly, it was akin to a hurricane that blows through and wrecks
a lot of stuff. But it certainly announces
itself. I mean, it might as well put
up a big dialog box that says YOU ARE OWNZORD BY BLASTER — Blaster was about as subtle
as a brick through a window.
Valve attackers were far cleverer and subtler. Their attack was focused on a particular
individual at a particular company and depended on slowly and carefully gathering
the information needed to launch further attacks, avoiding detection until the job
was finished. You can rapidly write and
disseminate a virus checker for “broad distribution” worms, viruses and Trojans, but
it is very hard to write a “virus checker” for custom built malware that only attacks
a single person!
second kind of attack I suspect is far, far more common than the first and ultimately
costlier. But since the first kind is
by its nature highly visible, and the second is by its nature as invisible as possible,
the former gets a lot more press.
need to solve this problem and produce a more trustworthy digital infrastructure. It
will not happen overnight, but I am very confident that we are on the right track.