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]

Date:	Thu, 4 Nov 2010 22:51:57 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Willy Tarreau <w@....eu>
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

* Willy Tarreau <w@....eu> wrote:

> On Thu, Nov 04, 2010 at 08:08:04PM +0100, Ingo Molnar wrote:
> > 
> > * Marcus Meissner <meissner@...e.de> wrote:
> > 
> > > > For example, on a Fedora testbox i have this version info:
> > > > 
> > > >   $ uname -r
> > > >   2.6.35.6-48.fc14.x86_64
> > > > 
> > > > Any attacker can download that rpm from:
> > > > 
> > > >   http://download.fedora.redhat.com/pub/fedora/linux/updates/14/x86_64/kernel-2.6.35.6-48.fc14.x86_64.rpm
> > > > 
> > > > And can extract the System.map from it, using rpm2cpio and cpio -i -d. That will 
> > > > include all the symbol addresses - without the attacker having any access to the 
> > > > System.map or /proc/kallsyms on this particular box.
> > > > 
> > > > I.e. on distro kernel installations (which comprise the _vast_ majority of our 
> > > > userbase) your patch brings little security benefits.
> > > > 
> > > > What i suggested in later parts of my mail might provide more security: to 
> > > > sandbox kernel version information from unprivileged user-space - if we decide 
> > > > that we want to sandbox kernel version information ...
> > > > 
> > > > That is a big if, because it takes a considerable amount of work. Would be worth 
> > > > trying it - but feel-good non-solutions that do not bring much improvement to 
> > > > the majority of users IMHO hinder such efforts.
> > > 
> > > Hiding the OS version is really quite hard I think.
> > 
> > Yes. 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.
> > 
> > Removing version info will upset some tools/libraries that rely on kernel 
> > version information for quirks though.
> 
> 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.

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

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.

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.

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

Thanks,

	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/