Q: What about 2.6.x and 3.x?
A: We're adding some hardening changes to RHEL-based OpenVZ kernel revisions that we use in Openwall GNU/*/Linux - http://www.openwall.com/Owl/ . We have no specific plans for a hardening patch for mainline kernels. For a currently maintained hardening patch for mainline kernels, see grsecurity at http://grsecurity.net . Note that grsecurity is maintained by third-party developers not affiliated with Openwall.
Q: What about new patch revisions for Linux 2.4.x?
A: None are currently planned.
Q: Where can I find other versions of the patch?
Q: I only have the patch for Linux 2.0.x or 2.2.x, where do I get a version for Linux 2.4.x (or vice versa)?
Q: Is the patch x86-specific?
A: Only the non-executable stack feature of the patch is x86-specific. The patch has been tested and is used on other architectures as well. In fact, I've released some minor updates of the patch after testing them on Alpha only in the past.
Q: Are there any issues with the patch on SMP boxes?
A: None that I am currently aware of. I've been running all versions of the patch since 2.0.33 on SMP.
Q: Why don't they make it into the standard kernel?
A: This is not a trivial question to answer. First, some parts of older versions of the patch (or equivalent, but different, fixes) are in fact in the kernel now. This is the reason the patch for 2.0.36 was smaller than it used to be in the 2.0.33 days. Now the patch for 2.2.13 is once again smaller than its last 2.2.12 version. :-) So, security problems in the kernel itself are typically getting fixed. It is, however, true that the security "hardening" features of the patch are not getting in. One of the reasons for this is that those features could result in a false sense of security. Someone could then decide against fixing a hole on a system they administer or in software they maintain just because of these kernel features. If such things happen, the security is in fact relaxed, not improved. The rlimit restrictions I have here are temporary hacks, to be replaced with a real solution (beancounters), so I'm not trying to get them into the kernel.
Q: I've applied the patch, and now my kernel doesn't compile?
A: Are you sure you've applied the patch exactly as shown in the README? Please try again with a known-clean source tree.
Q: Will GCC-compiled programs that use trampolines work with the
non-exec stack part of the patch?
A: Yes, if you enable the support.
Q: When I'm trying to use "print f()" in gdb on a Linux 2.2+ system
with your patch, my program crashes. What's going on?
A: The changes made in Linux 2.2 didn't let me port my old workaround for this from the Linux 2.0 version of the patch. You'll have to use chstk on the program you're debugging in order to use this feature of gdb.
Q: What does GCC use trampolines for?
A: Trampolines are needed to fully support one of the GNU C extensions, nested functions. When a nested function is called from outside of the one it was declared in (that is, via a function pointer), something needs to provide the stack frame. The bad thing is that GCC puts trampolines onto the stack (as they're generated at runtime). You can find an example in stacktest.c, included with this patch.
Q: How do you differ a trampoline call from an exploit attempt?
A: Since many buffer overflow exploits overwrite the return address, the instruction to pass control onto the stack has to be a RET. When calling a trampoline, the instruction is a CALL. Note that in some cases such autodetection can be fooled by RET'ing to a CALL instruction and making this CALL pass control onto the stack (in reality, this also requires a register to be set to the address, and only works this way on Linux 2.0). Read help for the "Autodetect GCC trampolines" configuration option.
Q: What about glibc and non-executable stack?
A: You have to enable trampoline autodetection when using glibc 2.0.x, or the system won't even boot. If you're running Linux 2.0, you will likely also want to enable trampoline call emulation to avoid running privileged processes with executable stack. With newer versions of glibc, only the "localedef" program, but not glibc itself, uses GCC trampolines.
Q: I've just compiled glibc 2.1.x on my system, but "make check" fails
while trying to load testobj1.so. What's going on? Will the newly
compiled glibc work with your patch in the kernel?
Q: What's the deal with glibc-2.1.3-cvs-20000504-dl-open.diff?
A: The non-executable stack part of the patch changes the default address shared libraries are mmap()'ed at. Unfortunately, some parts of glibc 2.1.x depend on this address being above ELF sections. This is a bug and it's been fixed in newer versions of glibc. The good thing is that the problem is only likely to show up with the little used ORIGIN feature, and only when the dynamic linker is run as a standalone program. It is thus highly unlikely that this will cause anything other than "make check" to break. You can, however, use the fix included with this patch.
Q: What does the procps-2.0.6-owl.diff patch do? Is it required?
A: This procps patch updates the stale utmp entry check, so that w(1) in procps 2.0.x up to 2.0.6 works correctly on systems with the restricted /proc option. If you don't experience any problems with w(1), you don't need to install the procps patch.
Q: What does the psmisc-*-owl-restricted-proc.diff patch do? Is it
A: When the "Restricted /proc" option is enabled, the entire process tree may no longer be visible to a user. Instead, multiple subtrees may be seen. This patch makes pstree(1) display those subtrees. It is nice to have, but it is indeed not strictly required.
Q: What is chstk.c for?
A: The patch adds an extra flag to ELF and a.out headers, which controls whether the program will be allowed to execute code on the stack or not, and chstk.c is what you should use to manage the flag. You might find it especially useful if you choose to disable the GCC trampolines autodetection. BTW, setting the flag also restores the original address shared libraries are mmap()'ed at, in case the program depends on that.
Q: What if an attacker uses chstk on a buffer overflow exploit?
A: Nothing changes. It's the vulnerable program being exploited that needs executable stack, not the exploit. The attacker would need write access to this program's binary to use chstk successfully.
Q: Do I have to reboot with an unpatched kernel to try out a new
buffer overflow exploit to see if I'm vulnerable?
A: No, you can use chstk on the vulnerable program to temporarily allow it to execute code on the stack. Just don't forget to reset the flag back when you're done. Also, be careful with relying on such tests: typically, they cannot prove that you're not vulnerable, they can only sometimes prove the opposite. Note that setting the flag on Linux 2.2+ systems will change the default stack location to be 8 MB lower than where many exploits expect it to be.
Q: Are any applications known to require executable stack and/or the
traditional default mmap() address?
A: Yes. Many Win32 applications and DLLs (such as some video codecs) are non-relocatable and must be loaded at their default address which must not be already taken by the shared libraries of a Linux application such as Wine or MPlayer. Simply invoking "chstk -e" on the "wine*" and "mplayer" binaries solves this problem. With Win4Lin, use "chstk -e dosexec". Some have reported that JDK 1.3 doesn't work unless chstk'ed, but many report it just working. Someone has reported XFree86 4.0.1 with old proprietary nVidia GeForce drivers to not work unless the X server is chstk'ed, but the X.Org server just works, including with proprietary nVidia drivers.
Q: Why did you modify signal handler return code?
A: Originally the kernel put some code onto the stack to return from signal handlers. Now signal handler returns are done via the GPF handler instead (an invalid magic return address is put onto the stack, which causes a return to kernel space to handle the "fault").
Q: What to do if a program needs to follow a symlink in a +t directory
for its normal operation (without introducing a security hole)?
A: Usually such a link needs to be created only once, so create it as root (or the directory owner, if it's not root). Such links are followed even when the patch is enabled.
Q: What will happen if someone does:
ln -s /etc/passwd ~/link ln -s ~/link /tmp/link
and the vulnerable program runs as root and writes to /tmp/link?
A: The patch is not looking at the target of the symlink in /tmp, it only checks if the symlink itself is owned by the user that vulnerable program is running as, and doesn't follow the link if not (like in this example).
Q: Is there some performance impact of using the patch?
A: Practically none. Normally the only thing affected is signal handler returns. I didn't want to modify the "sigreturn" syscall so there is some extra code to setup its stack frame, but it doesn't necessarily mean that signal handling became slower: benchmarks show that executing code on the stack was even slower on some processors. Either way, the difference seen on benchmarks is small as saved context checks and other signal handling stuff are taking much more time than the bits changed by the patch, and there's no measurable difference in performance of real world applications. Programs using GCC trampolines will run slower if trampoline calls are emulated. However, I'm not aware of any program that uses trampolines in a performance-critical place (would be a stupid thing to do so anyway).
Q: How does this patch compare with NSA Security-Enhanced Linux?
A: These two are not even similar, so it is hard to compare them. Rather, I'll describe them briefly:
The Openwall Linux kernel patch - a collection of security "hardening" features aimed at reducing the likelihood and/or impact of successful exploitation of certain classes of vulnerabilities in userspace applications, without requiring modifications to any userspace applications or libraries; also included are security fixes/enhancements to issues with the kernel itself (whenever the mainstream kernel is being too conservative or too slow at fixing security issues).
NSA SELinux - adds support for mandatory access control policies into the Linux kernel, and provides patches to certain userspace utilities to make use of said Linux kernel additions, with more userspace patches available from third parties (the kernel patch is useless without userspace applications and libraries patches); no security fixes/enhancements to issues with the kernel itself are being included (as far as I'm aware).
The two kernel patches can co-exist, and it may make sense to use both approaches on some systems, although there may be some issues with patch merging (you might have to apply some hunks manually). I have not tried that.
You could also want to consider RSBAC as a well-established generic alternative to SELinux. (Or rather, SELinux is an alternative to RSBAC, since RSBAC is an older project.) It can co-exist with the Openwall Linux kernel patch, too, and I know that some people and even Linux distributions (ALT Linux Castle, other minor ones) have been using these patches together.
Solar Designer <solar at openwall.com>
Powered by Openwall GNU/*/Linux - Powered by OpenVZ