oss-sec mailing list archives
Re: [Security] [oss-security] Re: /proc infoleaks
From: Brad Spengler <spender () grsecurity net>
Date: Tue, 7 Sep 2010 17:51:31 -0400
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/System.map or /lib/modules are perfectly visible on any distro. 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 security. -Brad
Attachment:
signature.asc
Description: Digital signature
Current thread:
- /proc infoleaks Sebastian Krahmer (Sep 07)
- Re: [Security] /proc infoleaks Andrew Morton (Sep 07)
- Re: [Security] /proc infoleaks Sebastian Krahmer (Sep 07)
- Re: Re: [Security] /proc infoleaks Marcus Meissner (Sep 07)
- Re: [Security] [oss-security] Re: /proc infoleaks Willy Tarreau (Sep 13)
- Re: [Security] /proc infoleaks Sebastian Krahmer (Sep 07)
- Re: Re: [Security] /proc infoleaks Jon Oberheide (Sep 07)
- Re: Re: [Security] /proc infoleaks Andrew Morton (Sep 07)
- Re: [Security] [oss-security] Re: /proc infoleaks Andrew Morton (Sep 07)
- Re: [Security] [oss-security] Re: /proc infoleaks Brad Spengler (Sep 07)
- Re: Re: [Security] [oss-security] Re: /proc infoleaks Sebastian Krahmer (Sep 07)
- Re: Re: [Security] [oss-security] Re: /proc infoleaks Brad Spengler (Sep 08)
- Re: [Security] /proc infoleaks Andrew Morton (Sep 07)
- Re: [Security] [oss-security] Re: /proc infoleaks Linus Torvalds (Sep 07)