Message-ID: <20101104223526.GC31236@1wt.eu>
Date:	Thu, 4 Nov 2010 23:35:26 +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 Thu, Nov 04, 2010 at 10:51:57PM +0100, Ingo Molnar wrote:
> > Quite honnestly, it's the worst idea I've ever read to protect the kernel. Kernel 
> > version is needed at many places, when building some code which relies on presence 
> > of syscall X or Y depending on a version, etc... [...]
> 
> Actually that's not true, since we have a kernel ABI, and since there's many 
> backports of newer kernel features into older kernels that it's generally not
> needed nor meaningful to know the kernel version for syscalls.
> 
> Returning -ENOSYS is the general standard we use to communicate syscall 
> capabilities.
> 
> In fact using kernel version to switch around library functionality is a bug i'd 
> argue.

I'm sorry Ingo, but I still don't agree. We've had several versions of epoll,
several (some even buggy) versions of splice() which cannot even be detected
without checking the kernel release. And those are just two that immediately
come to my mind. If we've been providing a version for the last 19 years, it
surely had some valid uses.

> > [...] If our kernel is so buggy that we can only rely on its version to be kept 
> > secret, then we have already failed.
> 
> That mischaracterises my suggestion rather heavily - which makes me suspect that you 
> misunderstood it. Here's the relevant section of what i suggested here:
> 
> > > Hard but it would be useful - especially if we start adding things like known 
> > > exploit honeypots. Forcing attackers to probe the kernel by actually running a 
> > > kernel exploit, and risking an alarm would be a very powerful security feature.

I have read it, but this does not require hiding the kernel version. You can
still keep your honey pots if you want (provided that they don't slow down
normal syscall path) and log suspect attempts. But if you're hiding the version,
those tricks will be used by valid programs too.

> An 'exploit honeypot' would be some small amount of 'detection' code for the 
> exploitable pattern of parameters (most attacks come via ioctls so we can add 
> detection for known holes without any performance hit), and the kernel would warn 
> the sysadmin that an exploit attempt has occured.

If we pollute the ioctl code with all the CVEs we have accumulated over the
years, I bet we'd get a performance hit and will probably introduce new bugs
due to the harder to maintain code.

> The point is to make it riskier to run exploits - not to 'hide version because we 
> are so buggy'. Unprivileged attackers wont be able to know whether a kernel is 
> unpatched and wont know whether trying an actual exploit triggers a silent alarm or 
> not.

In my opinion, hiding the distro-specific part of the version should not cause
too much harm, but still I find this useless.

You see, I've used the vmsplice exploit at one place. Do you know how I did ?
$ cat /etc/redhat-release

Then I opened the box and installed the DVD showing the same version on a
spare PC to experiment with it. Once I got the exploit to reliably work without
crashing the kernel nor leaving traces, I dared launching it on the target
machine and it worked. Uname -r was not involved there. I simply relied on
the fact that updating a distro is a pain at many places and that it's very
rare to find an updated one because of that, so they remain with the shipped
kernel for months if not years, and sometimes even because some product
vendors say "my product supports Red Hat kernel 2.6.18-128xxx" so they don't
want to risk losing the support because they don't understand anything to
versioning.

So if we make fixes easier to install, we'd probably have less issues with
unfixed code than if we try to pretend they're not vulnerable by hiding the
version.

> I.e. i think the only true break-through in kernel security will be to add credible 
> and substantial 'strike back' functionality - to increase the risks of detection 
> (which necessiates the removal of the information whether a kernel is patched or 
> not).
> 
> As i said it's hard - but it would be a rather break-through security feature for 
> Linux.

It requires hiding so many things for providing so little protection that I
really don't believe in it at all. Simply checking the system uptime the
last most date of /boot generally tells you precise info about the last
udpate.

> Not an 'arms race' thing where we just put obstruction in the road of 
> attackers - but some real, unavoidable risk not detectable by attackers - running on 
> most stock distro kernels. (so there would be a real economy of scale)
> 
> The kerneloops client could also collect exploit attempt stats.

Well, in my opinion, either the attacker is remote and you can already get
many info, or he's local and has time to precisely qualify the environment
in order not to leave the slightest trace. The rule is simple : if you don't
trust your local users, remain up to date. One day lag once and you lose.

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/

Powered by blists - more mailing lists