linux-kernel - Re: [Security] [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20101107125120.GA4627@1wt.eu>
Date:	Sun, 7 Nov 2010 13:51:20 +0100
From:	Willy Tarreau <w@....eu>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Marcus Meissner <meissner@...e.de>, security@...nel.org,
	mort@....com, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	fweisbec@...il.com, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org, jason.wessel@...driver.com,
	tj@...nel.org, Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Security] [PATCH] kernel: make /proc/kallsyms mode 400 to reduce ease of attacking

On Sun, Nov 07, 2010 at 01:32:32PM +0100, Ingo Molnar wrote:
> No. The 'exploit honeypot' mechanism i outlined is really simple, and it means what 
> i explained already:
> 
>  - attacker breaks into unprivileged user-space
> 
>  - attacker runs exploit
> 
>  - exploit attempt gets detected by the 'exploit honeypot' kernel code and a 
>    (silent) warning goes to the admin (via a syslog message for example)
> 
>  - attacker only sees that the attack did not succeed
> 
> This makes it _unsafe_ (for many types of attackers) to run an exploit locally.

It's already unsafe and has always been. When running local kernel exploits,
it's common to find lots of segfault traces in dmesg. It's common to hang the
machine (the vmsplice exploit had a 50% failure rate from my tests).

> > That's not much different than trying to fire the exploit itself. [...]
> 
> Erm, the difference is possible _detection_ via a silent alarm.
>
> There's a huge difference between 'attempting an exploit and being caught' and 'not 
> even trying the exploit because based on the kernel version the attacker knows it 
> wont work'.

And there's an even bigger difference between leaving traces of a failed
exploit attempt and successfully getting the exploit to work because the
system is not updated in time. That's been my point since the beginning,
most kernel exploits are run very early when released to the public. So
that's when a simple "uptime" will tell you it's safe to run your exploit.
And if you want to hide the uptime, let's simply check the creation date
of /dev/shm, or that a file you left in /tmp has not been removed by the
admin's scripts which clean that up at boot, etc...

In my opinion this is not efficient at all. Also, I've already been involved
in post-mortem diags on compromised machines. If the intruder is not a known
local user, he does not care at all being caught. Leaving rootkits everywhere
is generally not a problem for them, some don't even take care of clearing
the logs, because they bounced from already compromised systems.

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/