|| ||Ingo Molnar <mingo-AT-elte.hu>|
|| ||Re: [patch] Add basic sanity checks to the syscall execution patch|
|| ||Fri, 5 Sep 2008 17:42:21 +0200|
|| ||Benjamin Herrenschmidt <benh-AT-kernel.crashing.org>,
Andi Kleen <andi-AT-firstfloor.org>,
Arjan van de Ven <arjan-AT-infradead.org>,
linux-kernel-AT-vger.kernel.org, tglx-AT-tglx.de, hpa-AT-zytor.com|
* firstname.lastname@example.org <email@example.com> wrote:
> On 5 Sep 2008 at 13:42, Ingo Molnar wrote:
> > The other, more fundamental problem that nobody has mentioned so far is
> > that the check returns -ENOSYS and thus makes rootkit attacks _more
> > robust_ and hence more likely!
> > The far better solution would be to insert uncertainty into the
> > picture: some sort of low-frequency watchdog [runs once a second or
> > so] that tries to hide itself from the general kernel scope as much
> > as possible, perhaps as ELF-PIC code at some randomized location,
> > triggered by some frequently used and opaque kernel facility that an
> > attacker can not afford to block or fully filter, and which would
> > just check integrity periodically and with little cost.
> there's that adage about history being repeated by those not knowing it ;)
> for details see the series based around bypassing Vista's PatchGuard at:
i think Linux is fundamentally different here as we have the source
code, and could apply the randomization technique i mentioned:
> > [ It would be nice to have a 'randomize instruction scheduling'
> > option for gcc, to make automated attacks that recognize specific
> > instruction patterns less reliable. ]
and every box where it matters we could have a _per box_ randomized
kernel image in essence, with non-essential symbols thrown away, and
with a few checks inserted in random locations - inlined and in essence
unrecognizable from the general entropy of randomization.
Not that a randomizing compiler which inserts true, hard to eliminate
entropy would be easy to implement. But once done, the cat and mouse
game is over and the needle is hidden in the hay-stack. At least as long
as transparent rootkits are involved.
a successful attack that wants to disable the checks reliably would have
to patch the IDT and would have to emulate full kernel execution and
would have to detect the pattern of an alert on the hardware API level -
as that would be the only reliably observable output of the system.
Besides being impractical at best, at minimum a huge slow-down would
the only other option would be for a rootkit to transparently switch to
another, new, non-checked kernel image on the fly, while keeping all
user-space context safe. That's a feature Linux would like to have
anyway ;-) [and this could be made really difficult as well if gcc
inserted a modest amount of per kernel random noise in the layout of all
data structures / field offsets.]
to post comments)