Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 Sep 2010 17:51:31 -0400
From: Brad Spengler <>
To: Andrew Morton <>
Cc: Jon Oberheide <>,,, Sebastian Krahmer <>
Subject: Re: [Security] Re:  /proc infoleaks

> That being said, it *might* be acceptable to obfuscate the kernel-side
> addresses.  Still print them, but they're all zeroes.  I doubt if many
> tools at all are actually using those.  Perhaps a runtime knob which
> obfuscates those addresses for unprivileged users, something like that.
> That also being said, I'm not seeing any kernel-side addresses in
> slabinfo or zoneinfo anyway and I believe some distros already hide
> kallsyms.  More specificity is needed.

Do we have an inventory of the applications accessing these /proc 
entries?  We've been hiding them for years in grsecurity.  Some embedded 
systems also likely remove kallsyms completely (there's a config option 
for it), but we did find one init script looking in /proc/kallsyms for 
"nfsd" -- only one usage that I know of, and that was as root.

Definitely some work needs to be done here at the distro level, because 
it's pointless (as Enlightenment demonstrates) to hide /proc/kallsyms 
when /boot/ or /lib/modules are perfectly visible on any 

Also remember that this information is only useful pre-exploitation 
for non-distro kernels (since kernel image addresses involved there 
are publicly known).  So, for example, for choosing an arbitrary write 
target for a custom-compiled kernel.  Post-execution control, it's just 
obfuscation (you allow arbitrary code execution in the kernel and in 
userland -- the attacker can just as easily find and parse the symbol 
table in the kernel).

Fixing it via configurable init script in the distro seems acceptable to 
me (if an extra option were included in 2.6.36, distros wouldn't reap 
the benefit of that anyway unless it was backported to each kernel).  
The only situation where I see the userland fix not being equivalent (or 
at least requiring more work) is if /proc gets mounted in other 
locations at runtime (say in a chroot, even though doing so is poor for 
security to begin with).

The /proc/slabinfo isn't used for grabbing kernel addresses, but for 
obtaining somewhat reliable information about the current state of the 
different-sized slabs in the kernel (which is useful, but again not 
necessary, for kernel heap exploitation).

Obfuscating just the addresses is a reasonable compromise (but when it's 
not the default, distros need to know they have to enable it, making it 
not much different than implementing the userland measure -- if indeed 
there aren't any non-root users of these entries).  Leaving the symbol 
names can still be useful pre-exploitation for reliability purposes (to 
find out about different debugging options or other things that couldn't 
be determined by exercising some kernel functionality) but that's what 
makes it a compromise ;)

I know the impulse is to immediately copy what we're doing in 
grsecurity, but the reason we do some of the things in the way we do 
them is that we can be used on any distro and have no control over 
whatever distro that happens to be.  We also support other features like 
PaX's KERNEXEC and UDEREF which make the symbol/address removal more 
useful.  We're also able to make certain important assumptions about our 
users (eg. that they want security).  So make sure you're thinking 
carefully about what you're trying to accomplish, why you're doing it, 
and how effective it will actually be given the (lack of) synergistic 
features at your present disposal, instead of jumping into cargo cult 


Download attachment "signature.asc" of type "application/pgp-signature" (198 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.