This is the FAQ for the patch only, be sure to read the README first.
Q: What about 2.6.x and newer?
A: This is a discontinued project. We have no plans for a hardening patch for newer kernels.
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)?
A: https://www.openwall.com/linux/
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
required?
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>
