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."
I like the way, BSD makes non-exec stack default. I think in the latest linux kernel, you can make it non-exec at compile but it is not default.
Consensus is good, but informed dictatorship is better
google cache, in case of server is slashdotted
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.
OpenBSD does not secure by limiting or removing functinality. Instead, it secures through proper programming, working as a team, and tackling issues in sequence.
:)
I understand your joking, but point the next one towards the right area
...Microsoft's goal has been to add more saleable features and more handcuffs for their users. Bill has a moneymaking mania. Then they expect a month of bugfixing to make up for over 100 months of bugmaking.
OpenBSD, on the other hand, probably has 100 months of bugfixing up its collective sleeve. I wonder if they expect that a month of portting applications will make them more popular? (-:
IRL, a month of porting applications would simply mean an order of magnitude more security holes to fix.
Making OpenBSD completely thread-safe in preparation for multi-CPU stuff is probably a steep hill to climb, too. However, the kind of stuff that OpenBSD does well probably means that very few single-CPU OpenBSD machines will be CPU-starved until long after they're disk-I/O or net-bandwidth-saturated. Which means that it makes more sense to cluster than to proliferate CPUs in an already-saturated environment.
Got time? Spend some of it coding or testing
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...
Theo de Raadt writes:
If you're running a JIT compiler/interpreter or other dynamic code assembly, you sure as hell do.
I can see how you might be able to write dynamically generated code to a page, then turn off PROT_WRITE and turn on PROT_EXEC before jumping to it. However, this is almost certainly two trips into the kernel, each involving tons of permission checking. So performance will likely suffer, which negates the whole point of doing JIT in the first place.
I like his survey of MMU architectures, though.
Schwab
Editor, A1-AAA AmeriCaptions
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.
Ancient and venerable 24-bit CDC 3150 machine in 1970 solved buffer overflow problems by pre-writing return jump to execover (pass control to data area and bang, you're dumped) instruction throughout user space. When you got the dump, the ASCII interpretation was "ojoy". So you got about thirty pages of blue-bar printout saying "ojoyojoyojoyojoy...".
Thou hast damnable iteration, and art indeed able to corrupt a saint - Henry IV, Act I scene II
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.
A nonexecutable stack is no guarantee of safety. Solaris 2.6 demonstrated this here.
-- Good judgement comes with experience. -- Experience comes with bad judgement.
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.
VMS is probably a close second in terms of security. Its C-2 secure right out of the box. Plus most script kiddies would be left scratching their head trying to use it.
Only the State obtains its revenue by coercion. - Murray Rothbard
You just have to explicitly mprotect(2) the memory where it happen with PROT_EXEC|PROT_WRITE. The fact that on some OSes it can work without doing that is actually a bug in these OSes.
What the change is doing is the right thing, using a minimum privilege way to achieve more security. If some static code actually contain data that look like machine code it could be executed this wont be possible anymore.
Non executable stack by itself was far from enough as most program have some way of putting things on the heap or elsewere for an attacker and he could jump there instead of jumping on the stack. Coding an exploit for OpenBSD will get real tough now, even if there's an actual buffer overflow.
I'm gonna have to disagree with you on several points here.
1. I have found Open is actually easier to install than Free. Granted, this could be due to my love of purely simple methods, which the Open installer is. net is, in my mind, the hardest of the three, with free being very much in the middle.
2. I fail to see how Open is slwoer and more limited. It is true that Free has the most amazing tcp stack in production today, but Open's is pretty tight, and is plenty efficient in disk I/O and CPU usage. Its also not limited in any way. The stock install has a lot less "stuff" in it than most other OS's, but I consider that a definate bonus. "Ports" in a few extras, and you have an awesome, httpd, ftp, mail, dns, whatever server. In my company, we have dual purpose dns/mx backup OpenBSD machines.
3. While it is true that OpenBSD makes a dandy firewall, and quite frankly, I would use nothing else but OpenBSD for said purpose, that's not all its good for, and this "typecasting" has to stop. Does just fine in any other role too, hell, I have an OpenBSD DESKTOP. DESKTOP!
4. As for an Open box getting owned, not surprising. The final step in a secure OS, is knowing how to maintain it, and miantaining Open is no picnic, once free is up and running it is far easier to lean to patch it. Both are fairly simple once ya get the hang of it, but the free learning curve is much faster. And quite frankly, a lot of businesses deploy tons of freebsd machines, lots of admins know it. Open is a newer project, with a smaller real world footprint.
Just my unspellchecked thoughts. Its almost my birthday, I no longer feel compelled to check my typos out.
--Nuintari
slashdot : where an opinion can be wrong.
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.
Secondly, who the hell are you? Stop impersonating me on Slashdot.
--
Theo de Raadt
Founder, OpenBSD project
The bigger problem is that the principle of least privilege is not adhered to in world of Unix. Programmers will always write bugs and applications will always have vulnerabilities that can be manipulated. Manipulation of services should only effect the service being manipulated, not the whole system. For example, services should have NO access to anything by default.
That is very much the approach that OpenBSD is taking - e.g. with privilege separated OpenSSH. If you exploit OpenSSH before authentication, you are unprivileged in a chroot that you can't write too. While this is not invulnerable (you may still abuse kernel bugs to escalate your privilege), it is a good deal better than before. OpenBSD also provides you tools with which you may further protect yourself: systrace - a system call policy checker.
Forget about security through obscurity, this is security through paranoia. Sometimes, it is justified.
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.