Slashdot Mirror
OpenBSD Gets Even More Secure
Telent writes "As seen in this post by Theo de Raadt, OpenBSD is getting even more secure, working on smashing script kiddies running buffer overflow exploits dead. Tightening PROT_* according to the POSIX standards and creating a non-executable stack on most architectures are just two of the recent enhancements, most of which are in -current now."
A few other people would agree that OpenBSD is the most secure OS. Although I'm a Debian user, kudos to the OpenBSD team on their work.
Your hair look like poop, Bob! - Wanker.
You may get your SMP in OpenBSD soon. From what that article says, they are supposed to have a kernel up by now (although that was their estimate, so you can never be sure).
I prefer to use BSD (Free* or Open*) as servers, as opposed to Linux.
Why?
If you've ever installed a Linux distribution, you will immediately note the number of third-party libraries and applications installed on a 'base' system. This is frustrating for me, because for the most part I may not want all those extra applications installed, because it clutters up the system, and there may be various vulnerabilities present that I'll be open to.
Instead I prefer to use BSD in these situations, because when you install the operating system, everything with a few choice exceptions (ie, gcc, apache, less) everything is part of the BSD operating system, no third party apps are installed unless you choose to at install time.
So when I install a BSD server, its clean from the get go. If I want bash, I have to install the package. This way I get control over what is on my system, and spend far less time adding what I want, instead of removing what I don't want (in the case of a Linux distro).
I use MacOS X laptop, which is the vision for what I always wanted my linux desktop systems to be. I can play DVD's, get sound working, simple updates, bash, gcc, ircII, web browsers which don't have problems on most sites, beautiful MP3 application, mail, etc.
For me, I don't even bother with Linux except for testing program portability, or for wireless lan-related applications (airsnort).
Man watching 6 MSCE's around a sun box, looks alot like the opening scene's of 2001:space odyssey...
Put simply, "Smashing the stack" is a method of overwriting variables within a program (which are located on "the stack") with malicious CPU instructions. When done properly, the vulnerable application will jump to those malicious instructions and do Bad Things(tm).
Preventing the CPU from executing code located on the stack will in many/most cases prevent these malicious instructions from ever running (because they're located on the stack).
For a detailed explanation, see Smashing the Stack For Fun and Profit by Aleph One.
A common bug in programs is that when they are receiving input (from the disk, from the keyboard, but most relevantly, from the Internet), they forget to make sure that they have enough room to "write down" the input they are receiving, and so they end up writing right past the end of their scratch area and over other stuff. Typically, this will cause the program to malfunction and/or crash soon afterwards.... BUT:
Years ago, crafty nasty little hax0rs realized they could use this type of bug to gain control of a computer remotely via the Internet. What they do is they find a computer running a program that has this sort of bug, and then send it input that is too big for the program's buffer, and contains a little program. The buggy program duly writes the input onto its stack, munging some of its other data -- and the hacker has formed the input "just so", so that the data it overwrites is the data governing what the computer will do next. So instead of just crashing, the program then executes the hacker's program. The program then usually "unlocks the front door" of the computer to the hacker, allowing the hacker to control the computer by remote.
Making the stack non-executable means the the computer doesn't allow itself to execute any code that is located in the stack. This means that the hacker can upload his evil program, but he can't trick the computer into running it.
Why this feature hasn't been standard in all OS's since the invention of the MMU, I cannot fathom.
I don't care if it's 90,000 hectares. That lake was not my doing.
There are several reasons why Linux does not have non-executable stacks yet...
One of them is that gcc and the kernel use trampolines. From the gcc docs:
AFAIK, linux uses trampolines at least in these places:
Both problems can be addressed (the openwall patches take care of the kernel trampolines), but it's not as easy as turning off the PROT_EXEC bits in the stack.
Also, a non-exec stack is not a silver bullet: it only makes exploiting buffer overflows somewhat harder. Check out this article from Solar Designer (the OpenWall patch author).
On top of the above:
You may now understand why Linus has so far judged that a non-executable stack was more trouble than it was worth.
The OpenBSD team is a really great group of hard-working coders that don't stop with writing just average code.
This latest security measure goes to show why they're still #1 when it comes to really closing up a machine's holes to prevent abuse and unwanted infiltration into a system.
Unfortunately, they still can't get UltraSparcIII documentation that they need for their project.
I urge you all to contact SUN Microsystems and demand that they hand over the details of the US III series computers.
*nix.org -- Latest article > "Taming OS X"
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
What is done is protecting memory zones created by the linker, mostly memory zone holding constants and static variables, so no there's no executable code in this area.
When you write a JIT you allocate your own memory on the heap and then compile your code there. On order for this code to be executable you have to mprotect(2) the memory zone holding your code with the PROT_EXEC flag, or PROT_EXEC | PROT_WRITE if you want to be able to modify it afterward. Anyway you can change the memory protection at anytime so anything you could do before you still can do.
On Intel processors, read- and execute-permission for a memory page is only one flag. For this reason, if you make the stack nonexec on Intel machines, the cpu will have to do a lot of context-switching, because all the protection faults that occur when an application tries to read from a non-exec page need to be handled by the OS kernel.
On SPARC, Alpha or POWER CPUs there is one flag for the read-permission and another one for the execute-permission.
To prevent exploitation of buffer overflows, I believe that we simply need much better hardware.
For example, IBM's AS/400 has Hardware pointer protection. It is absolutely impossible to fake certain types of pointers on the AS/400, because the CPU will recognize when a pointer has been overwritten due to a buffer overflow.
That's how REAL bufferoverflow-protection works. If you just make dataregions nonexecutable, you can still parameterize some kind of library function (how about execve()?) and make the vulnerable program jump into the codesegment to execute the library function with the parameters specified by the attacker.
AS/400s simply 'abuse' one bit in the ECC code as a flag for marking valid pointers.
For every 64 bits in RAM there should be 1 flag bit, which tells the CPU whether the data in memory is a valid pointer or not.
An instruction like LEA (Load effective address) should then implicitly set the flag, and instructions like MOV (Move Data, actually a copy instruction) should always clear the flag.
If a RET (return from subroutine) instruction tries to load an unflagged (=invalid) pointer, the CPU should trap to the OS kernel.
For legacy application, that are too damn stupid to use pointers in a correct way, a privilege could be added to the OS kernel to allow an application to use even invalid pointers.
Furthermore, read- and execute-permission should be separate flags and all stack- and heap-pages should be nonexec by default.