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...
I do not have any links, but stack smashing is when you pass a large parameter to a program. If the programmer did not check the size of the input and assumes that it is smaller than the actuall size of the parameter. This then overwrites the stack(variable stoarge) and can get into the return section of the program. If it is able to get into the return section, OS's with EXEC Stacks may execute code that was passed with the overflowing parameters
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.
Well, most C compilers allocate temporary variables on the stack, which is the same place that they use to keep track of where the currently-executing function was called from, so they can return to the previous function.
If your program overflows the end of a temporary string or array (due to a bug in the error-checking, most likely), it can overwrite other things on the stack, including the return address of the current function call.
So, the attacker sends in an enormous string, which "just happens" to contain some executable code that does something nasty, followed by the address of that same code.
The new return address overwrites the one on the stack, so that when the function returns, it actually jumps into the previously-loaded data on the stack, which then does something nasty.
Making the stack non-executable causes the program to crash when you try to exploit it this way.
You can still overwrite data on the stack, which might still allow you to get a program to misbehave, but at least you're limited to running code that's already in the application.
Some of the other changes mentioned in the paper try to make it harder to exploit overwriting data on the stack, too.
Hope this was helpful,
-Mark
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.
It's has got more to do with priorities rather than budget. Windows was meant to be more of a "user-friendly consumer OS"... Although the security of Windows is at you say not as good as openbsd, I doubt that patching openbsd is at easy as opening the default browser, clicking on the Tools toolbar and click Windows Update.
Not trolling here, just showing another perspective to the issue.
Welley Corporation - SLM Scammers
Quick explanation -- (really you should google for this info but oh well)
:-) )
The stack is a LIFO (Last in First out) data structure. OS's and programs use it to store all sorts of data, but one thing it's commonly used for is storing return addresses for subroutines and such.
By "stack smashing" what people mean is the typical goal of a buffer overflow attack. A program that doesn't do bounds checking on an array of data can be fed a huge amount of data that exceeds the length of the buffer that it has allocated to hold that memory. It then starts walking over other parts of memory and runs into the stack (which exists in memory just like everything else).
If you overwrite a return address in the stack with a pointer that points to some code that you've written to memory with the buffer overflow you just did, you can execute arbitrary code and thusly take control of a system (with whatever privileges the program you just attacked uses).
Since a lot of your overflowing data is going into the stack, it's a potential space for a lot of the code you might want to execute. Since the stack should only hold data and pointers, not code, it's safe to make it non-executeable with the MMU. This makes it harder to write a buffer overflow exploit, although it doesn't totally prevent it (since you can stick your malicious code in non-stack space as well).
(Feel free to flame/mod me down for any mistakes in this explanation.
Seriously, without MS would there be a reported "shortage of qualified computer personnel"?
If all these exploits are beaten before they are even implemented how will one prove their worth to their employers?
Damn it, I thought that SQL Slammer was a saving grace. We didn't have our servers at sp3 but then again they are behind a dual stage firewall so we had no hicup at all. However, I got the time at work to install patches as a result of the media.
To summarize: don't eliminate vunerabilities because you'll just be eliminating someones job (both the admins and hackers).
[end sarcasm, or my attempt at sarcasm since I haven't seen any around these parts since 1995]
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.
oh look, another poser... fook off!
For the 64 bit versions all pages have proper rwx permissions applied as specified in VirtualAlloc etc., but I'm not sure if the stack is no-exec by default.
Still, there are bound to be tons of protocol implementation errors that have nothing to do with fixed length buffers :P
I'll leave that as a start.
I don't want knowledge. I want certainty. - Law, David Bowie
FreeBSD's better for the desktop due to a much more comprehensive ports collection.
FreeBSD supports SMP, too - not much use for firewalls but handy in a lot of other roles.
FreeBSD is also a better choice for those new to the *BSD world as it's more popular - there's more help out there for it
No disrespect to OpenBSD - it's a fine OS - but so is FreeBSD. And, IMHO, for most roles, FreeBSD is a better choice. Each to their own and all that, though.
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.
can't install it on my main production servers. Why? Because it STILL does not have locales. And without locales cyrillic doesn't work in mysql, zope and other applications :( OpenBSD makes a great private net forwarder in remote locations tho.
And then they ship sendmail and BIND with it.
The BIND that comes with OpenBSD is an audited V 4.x IIRC. That should suffice for many many users, those that need 8.x or 9.x can find it them the ports tree. The sendmail is locked down as well and doesn't accept connections by default.
Nice FUD otherwise.
Trolling is a art,