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 22:41:34 +0200
From:	Willy Tarreau <w@....eu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	pageexec@...email.hu, 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

On Fri, Sep 05, 2008 at 01:42:33PM +0200, Ingo Molnar wrote:
> The far better solution would be to insert uncertainty into the picture: 

till there OK :-)

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

"can not" above is the unrealistic requirement unfortunately.

> When it finds a problem it immediately triggers a hard to block/filter 
> vector of alert (which can be a silent alarm over the network or to the 
> screen as well).
> 
> that method does not prevent rootkits in general (nothing can), but sure 
> makes their life more risky in practice - and a guaranteed livelihood 
> and risk reduction is what typical criminals are interested in 
> primarily, not whether they can break into a particular house.
> 
> If we implement it then it should not be present in distro .config's, 
> etc. - it should be as invisible as possible - perhaps only be part of 
> the kernel image .init.data section in some unremarkably generic manner. 

Then they will simply proceed like this :
  - patch /boot/vmlinuz
  - sync
  - crash system

=> user says "oh crap" and presses the reset button. Patched kernel boots.
   Game over. Patching vmlinuz for known targetted distros is even easier
   because the attacker just has to embed binary changes for the most
   common distro kernels.

Clearly all this is a waste of developer time, CPU cycles, memory,
reliability and debugging time. All that time would be more efficiently
spent auditing and debugging existing code to reduce the attack surface,
and CPU cycles + memory would be better spent adding double checks to
most sensible functions' entry points and user data processing.

Regards,
Willy

--
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/