Hackers Libray: Chapter 14 The Grsecurity patch

Among the many features provided by this Linux Kernel patch, we have been able to test the Open Wall and the PaX memory protection systems on 2.4.17 Kernel. Note that they mutually exclude each other.

14.1 A few drawbacks

Both PaX and Open Wall prevent any code in the stack to be executed, but only PaX stops the execution of heap-located code. That is why we prefer this kind of protection, as we have seen the risks of heap overflows.

Nevertheless, some applications, such as XFree86 server 4, cannot execute on a system with these restrictions. That may be a problem, at least a handicap.

Although some solutions are proposed (PaX trampoline emulation) we refuse them because, by allowing some exceptions, we give up a part of the security we want to improve. So, we think we should accept to be unable to run some applications on one side, and have an increased security level on the other side.

A small note about trampolines When nested functions (functions declared inside a function) are implemented, they require small pieces of code to be generated at run time, called trampolines. They are located on the stack. The way trampolines must be generated is determined by the compiler (gcc as far as we are concerned). The idea behind this is to be able to jump to the real nested function address. Both Open Wall and PaX allow ways to use this mechanism.

Another really annoying point is the performance loss; although we have not experienced much trouble with our short tests, we are conscious that they are not as representative as intensive benchmarks based on a few defined applications would be. Moreover, PaX documentation mentions this drawback.

14.2 Efficiency

PaX has revealed a very good resistance to our tests, as we have not been able to make any of our exploits work on a PaX-patched system.

Altough the usefulness of making some memory pages non-executable has been heavily discussed, we consider it as another defense to break through, which should NOT be considered as the ultimate protection!

But providing:

• a non-executable stack

• a non-executable heap

• randomization in mmap

is a good way to avoid many script kiddy exploits based on basic buffer overflows or more sophisticated return-into-libc attacks.

It may be interesting to be alerted when violations of a non-executable memory page occur: this is done thanks to PaX log messages, which is simple but how useful!

Another interesting point of these security patches is the diversity of their features: PaX detects DoS, Open Wall offers plenty of varied protections, such as link or FIFO control in /tmp or new /proc restrictions.

Moreover the global Grsecurity patch provides many other possibilities, from file system to process or networking protections. This patch is definitely highly recommended to enhance a Linux box security.

Conclusion

A general solution

After this study, we can pretend that on servers (or typically, machines that do not require an X server), a solution based on Libsafe and PaX is rather robust, and will prevent most generic buffer overflow attacks. So we consider this set represents a satisfying and reliable answer to our security questions.

We can pretend this because they are quite complementary: Libsafe may be challenged by trying to call unexpected functions, but PaX provides mmap randomization which makes it harder, and PaX may be overcome with return-into-libc attacks, but overflowing a buffer to write in a function return address would probably be prevented by Libsafe.

Nevertheless, it cannot be called perfect or unvulnerable; some exploits still may be performed, but we can bet it will not be script kiddies-like attacks, as they will require a more accurate knowledge of the system, and a good programming knowledge, as well as many tries probably before succeeding.

Using Stack Shield for compilations will also be a good point on such machines.

Unexplored fields

The theory on buffer overflow exposed in the first part is more or less general. Most of the exploits could be applied on either a unix or a windows box. The only exploits limited for linux are the very low level ones. For instance those based on:

• elf specifications, such as those modifying the GOT

• unix or linux library, such as the one playing with dlmalloc

The other parts are only unix dedicated and concern tools for protecting a unix system against buffer overflows.

Therefore there are few things in this paper dealing with buffer overflows under windows. Nevertheless the world of buffer overflow under windows is also huge and requires a study at least as long as the one performed here. The methods are roughly the same in theory but from a practical point of view they rely on different tricks. The biggest difference comes from the fact that the sources of the software are not available. So a first job consists in disassembling the source and examining it in assembly. Furthermore some tricks depend on the windows operating system itself and the choices made for its implementation. Thus a good knowledge of the windows operating system and of the kernel are required. Which is a huge task, since the sources of windows are closed in contrary to Linux. But this is not a warranty of security, and there are a lot of buffer overflows under windows.

Protecting tools also exists, but are not free most of the time. Among the available free software there is

BOwall (http://www.security.nnov.ru/bo/eng/BOWall/) which does roughly the same things as Open-Wall or Pax.

Bibliography

[1] Aleph One, "Smashing the stack for fun and profit", Phrack Magazine 49

[2] Clifford Yago, "Securing the stack on Red Hat Linux 6.2 and 7.0 systems with Libsafe 2.0"

[3] Benjamin Karas, "Writing privileged Programs"

[4] Ivan Krsul, Eugene Spafford, Mahesh Tripunitara, "Computer Vulnerability analysis" [5] Rafal Wojtczuk, "Defeating Solar Designer's Non executable Stack Patch" [6] Solar Designer, "Openwall"

[7] Bulba, Kil3r, "Bypassing Stackguard and Stackshield", Phrack 56

[8] Rix, "Smashing C++ VPTRS", Phrack 56

[9] Michel MAXX Kaempf, "Vudo an object superstitiously believed to embody magical powers", Phrack

[10] Nergal, "The advanced return into libc exploits", Phrack 58

[11] Solar Designer, "Getting around non executable stack (and fix)"

[12] John MacDonald, "Defeating Solaris/Sparc non executable Stack protection"

[13] Tim Newsham, "non exec stack"

[14] Grugq, "Cheating the ELF"

[15] Crispin Cowan, Calton Pu, Dave Maier, Heather Hinton, Jonathan Walpole, Peat Bakke, Steave Beattie, Aaron Grier, Perry Wagle, and Qian Zhand, "StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow"

[16] Crispin Cowan, Steve Beattie, Ryan Finnin Day, Calton Pu, Perry Wagle and Erik Walthinsen, "Protecting Systems from Stack Smashing Attacks with StackGuard"

[17] Scrippie, "Inebriation"

[18] Steve Ellis, "Solaris passwd Non executable stack locale exploit"

[19] Crispin Cowan, Carlton Pu, "Death, Taxes, and Imperfect Software: Surviving the inevitable"

[20] Christophe Blaess, Christophe Grenier, Frederic Raynal, "Avoiding security holes when developing an application - Part 1: permissions, (E)UID and escape shells"

[21] Christophe Blaess, Christophe Grenier, Frederic Raynal, "Avoiding security holes when developing an application - Part 2: memory, stack and functions, shellcode"

[22] Christophe Blaess, Christophe Grenier, Frederic Raynal, "Avoiding security holes when developing an application - Part 3 : buffer overflows"

[23] Frederic Raynal, Samuel Dralet, "Protection contre Sexploitation des debordements de buffer -Introduction"

[24] Istvan Simon, "A Comparative Analysis of Methods of Defense against Buffer Overflow Attacks" [25] Hiroaki Etoh and Kunikazu Yoda, "Protecting from stack-smashing attacks"

[26] Arash Baratloo, Timothy Tsai, Navjot Singh, "Transparent Run-Time Defense Against Stack Smashing Attacks"

[27] Arash Baratloo, Timothy Tsai, Navjot Singh, "Libsafe: Protecting Critical Elements of Stacks"

[28] Timothy Tsai, Navjot Singh, "Libsafe 2.0: Detection of Format String Vulnerability Exploits"

[29] Markus Wolf Klog, "The Frame Pointer Overwrite"

[30] Matt Conover, "w00w00 on heap overflows"

[31] www.securiteam.com

[32] www.securityfocus.com

[33] www.rootshell.com

[34] www.synnergy.net

[35] www.blackhat.com

[36] The web site of Prelude, www.prelude-ids.org

[37] The web site of stackshield, www.angelfire.com/sk/stackshield