Security-improving technologies which could be deployed now [LWN.net]

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 16:34 UTC (Thu) by job (guest, #670) [Link]

I believe it is the fact that it does not prevent buffer overflow
exploits. There was a big discussion a couple of years ago when someone
wanted a non-executable stack in Linux. It wasn't settled until Linus
showed how to modify exploits so they worked without actually executing
anything off the stack. (Hint: There are lots of things that can be
interesting to change without actually being executed, such as return
addresses.)

When Linux has a non-exec stack by default (or when everyone are on
x86-64), all the exploits will use those techniques instead. It's harder
to write, but most exploits aren't easy to write in the first place.
Either it needs to be completely safe, such as using range checking
compilers (taking the performance penalty) or we shouldn't have it at all
by default. Obscurity buys nothing.

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 21:23 UTC (Thu) by bluefoxicy (guest, #25366) [Link]

PaX is not obscurity. It is impossible to directly inject code in a full PaX environment; and it is not guaranteeable to attempt to execute pre-existing functions which are stored at an unknown address. You would be able to write executable code to a file, mmap() it, and execute it; but only if you could guess where mmap() is.

A system relying on security through obscurity may
have theoretical or actual security vulnerabilities,
but its owners or designers believe that the flaws
are not known, and that attackers are unlikely to
find them.

-- http://en.wikipedia.org/wiki/Security_by_obscurity

If you examine a system for a month, all of it existing on read-only media (such as a Live CD), you can gather all useful information out of it. Then, the machine is rebooted, and the system comes back up, no alterations. Everything useful about address space layouts you have is lost, assuming you could gather that anyway (obscured /proc/<pid>/maps would prevent that). Using just the information you now have, you can't figure out where sshd, Mozilla, or apache have libc (and thus mmap()).

This isn't obscurity. You as the attacker know that you can still ret2libc, and you know all about the randomization. You can't from your end examine the address space and gather the data that you need to perform an attack. This is somewhat analogous to guessing a randomly generated password that changes every time the program is run.

So what you have here is that it's actually impossible to inject code directly; and that indirectly injecting code requires the execution of pre-existing code. The execution of pre-existing code can't be guaranteed any more than (on x86) guessing a 2.5 (3.75 on amd64) character aA1# password (92 possible values per character) in your very best case; except every failed attempt causes the "password" in this analogy to be recreated from random data independent of its previous values. Have fun, good luck, and learn to pray.

The point here isn't to hide things from the attacker; it's to make things unpredictable, AND hide them from the attacker. If the attacker can't predict the value of something he needs, then he's for all intents and purposes shooting at a silent, moving target while blindfolded; whereas with security by obscurity he's shooting at a fixed target that he can simply hammer repetedly once he's learned its location.

Security-improving technologies which could be deployed now

Posted Oct 21, 2004 21:30 UTC (Thu) by bluefoxicy (guest, #25366) [Link]

"Then, the machine is rebooted,"
"Using just the information you now have, you can't figure out where sshd, Mozilla, or apache have libc"

"changes every time the program is run"

I feel I need to clarify here that the reboot in the example was done to rerun *everything*, including init and all services. You could also init -U to reload init; telinit 1 to return to maintenance mode; restart all base system services; and then go back to normal mode and log back in. This route would accomplish the same thing--reloading all programs. It would, of course, be a long and annoying process that would be more quickly completed by a reboot (or kexec).

In short, the kernel does not need to be reloaded to rerandomize the address space of individual applications.

Also notable here is that I'm not contending bugs at kernel level, or information leaking bugs which you may have discovered during the month of examination; these are natural bugs which must be fixed, since they can't be protected against anyway and are thus out of scope.