root kits in SMM mode
Sampo Syreeni
decoy at iki.fi
Mon May 12 15:56:56 EDT 2008
On 2008-05-12, Perry E. Metzger wrote:
> I'd been wondering for years when someone would set malware up to run
> in systems management mode on x86 processors. Now someone has done it:
>
> http://www.pcworld.com/businesscenter/article/145703/hackers_find_a_new_place_to_hide_rootkits.html
In the information preservation circles which of course mind failure and
error tolerance, they they talk about "hard/fast vs. soft/slow"
failures. Soft failure implies the sort of slow, creeping, difficult to
detect failure mode that constitutes corrosion, bit rot and the like. A
hard fail is one that either happens, catastrophically, or doesn't
happen at all. I.e. a hard fail is the prototypical "digital" failure
mode and the soft one is its "analog" counterpart. For example the use
of error correcting codes has lead to hard drives and high end
microprosessors being the hard, binary failing type, by design, whereas
voice communication seems very difficult to make anything but "soft".
That happens because CPU's are designed to fail fast and to be replaced,
whereas analog tape degrades controllably and is gone when it is,
gradually but expectedly. RAID tries to stage the process so that a) we
can detect when harm was done, b) replace the faulty component, and then
c) fully reconstitute the data with perfect ditital fidelity before
irretrievable loss has even happened. Even that is predicated on the
assumption that the distribution of loss is bounded in some sense, which
it usually isn't, but at least we're approximating the relevant
probabilistic loss-of-value curve with more precision...
I think the distinction between soft and hard failure well describes the
failure mode that is inherent to secure(d) hardware, protected modes and
the like. Here, there's a hard obstacle to be beaten if you want to
surmount the protective cover; otherwise it just works and if it
doesn't, then it fails completely. The first barrigade is what the
designers concentrated at, in order to protect the soft, all-powered
interior core/trench of the supervisor mode.
They wanted to produce an insurmountable obstacle, and don't get me
wrong, perhaps they even succeeded at that. Perhaps they actually
managed to prove the security under plausible assumptions.
But then, perhaps not, and after that the soft underbelly always lends
itself to misuse. Even the designers of RMS Titanic didn't consider that
one final, fatal failure mode, which then bought the ultimate, historic
failure upon them. The design certainly was very good and based on the
entire body of existing knowledge at the time, accessible to the
designers. A priori it should have been more than sufficient to keep the
ship afloat, ex post it suddenly wasn't.
In the security/crypto frame of thought, I would translate that as two
separate things, a la Frank Knight (in "Risk, Uncertainty and Profit"):
a) you'll want to control the known, quantifiable, statistical risk so
that the costs and benefits equal out, and b) defend against what you
genuinely do *not* know ("uncertainty") by building in additional
categorical protections.
In the security context, and in both cases, you'll also want to follow
economics as best you can. With regard to risk, you'll want to follow
the continuous marginal effort/benefit curve of attack. It's always
going to be nonlinear, so any fixed, single counter-measure likely won't
be enough to cover all of the bases, because it would lead to a
step/kink in your countervailing curve. Usually you also cannot device
easy countermeasures that yield continuous and comparable incentives.
So, you'll have to approximate from below; that leads to a number of
counter-defences approximating the threat curve from below.
As for uncertainty, that cannot be quantified by definition, but we do
have qualitative/categorical defences against it. Like using "different
modes of defense/thought". "Distributed concerns." Quantitative burdens
on distributed clouds of executives, arranged to be "less susceptible to
influence than the general social network." There we have to apply the
(very underdeveloped) theory of coalitional game theory, social choice,
public choice and what not.
Finally, to return to the ground, in the scenario Perry describes, the
problem is that nobody even *tried* categorical defense *beyond* the
first breach. It was just assumed that the one impregnable wall (the one
between SMM and the rest of the x86 modes) was enough and perfect. In
reality, in order to defend against what you do *not* know, you'll need
multiple walls, of different kinds and degrees of fortification, or a
fundamentally different sort of authorization structure (which won't
*remove* the problem, but *will* shift the threat curve in the single
user, home application).
That eventual privacy catastrophe might never come about, but as Perry
says, in the current state of things, it's bound to happen over and over
again. As it just happened with SMM.
--
Sampo Syreeni, aka decoy - mailto:decoy at iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography
mailing list