linux-kernel - Re: [patch] Add basic sanity checks to the syscall execution patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 5 Sep 2008 17:42:21 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	pageexec@...email.hu
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Andi Kleen <andi@...stfloor.org>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, tglx@...x.de, hpa@...or.com
Subject: Re: [patch] Add basic sanity checks to the syscall execution patch

* pageexec@...email.hu <pageexec@...email.hu> 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:
> 
>   http://uninformed.org/?v=3
>   http://uninformed.org/?v=6
>   http://uninformed.org/?v=8

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 
occur.

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.]

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/