Default FreeBSD security

C

CoTones

Don't shoot the messenger. Please no flame wars and trolling! This is the FreeBSD forum, so it's very interesting how developers explain this (again, please - this is not about OpenBSD or Theo de Raadt!) I'm only interested in FreeBSD developers' thoughts on their OS ):

http://www.openbsd.org/papers/ru13-dera ... 00034.html

Other OS'es:
http://www.openbsd.org/papers/ru13-dera ... 00030.html

I guess, that poor quality applications break a lot if these features are enabled. True or wrong?

Thank you for patience,
CoTones
 
Stack protection is on by default in the base system of FreeBSD 10 as far as I know. The problems are in the ports(7) system where linking together code compiled with stack protection on but done with different compilers (Clang and GCC) isn't working properly yet.

I guess, that poor quality apps breaks a lot if these features are enabled. True or wrong?
Click to expand...

Wrong. Any program that breaks because the stack protector is enabled is not worth using.
 
I fail to see how (not) randomizing virtual memory address space section offsets or segment choice therein are a security feature (or breach).
 
It's mostly to do with randomizing the addresses at which libraries are loaded. Specifically libc. A lot of exploits depend on the predictability of the addresses at which libraries are loaded. Once you know the base address of a library you can use the 'standard' offsets to use functions within those libraries without having to load them. You basically hijack the libraries that were loaded by the program you exploited. This creates smaller and more versatile exploits. By randomizing the addresses you make it harder for the exploit to successfully find the base addresses of libraries, making it more difficult to actually do something "useful" once you've triggered a buffer overflow for example.
 
It is indeed harder to execute a procedure if you don't know its specific address, but it isn't impossible, especially if callback procedures are used, where the stack layout local to a certain part of program text of let's say the konqueror web browser is well known, so what needs to be done is to track the magic cookies (i.e. return addresses) to find the library offsets for QtCore, kdelibs*, ..., as the stack layout of any of the procedures on the call stack is known to the attacker in forward (because he has the same package after all).

In C++, the exception magic as well as global destructor witchcraft (I think it's called __cxx_fini or something like that) is always present above the main() procedure, so I always have the libc++/libstdcxx offset, and the libc++/libstdcxx has references to the libc.

To really obfuscate the address space you would need the stack protector/propolice to push system CRNG based stack paddings at runtime, and permutate the section contents and their according symbol map entries at load time (which would break a lot of ports which assume BSS/constdata section content to be locally related) instead of just adding random offsets to intervals of virtual memory.
 
You must log in or register to reply here.
Back
Top