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
One day, Theo is going to decide that allowing people access to the HTTP port of the dist machine is just too big a risk, and OpenBSD really will be the most secure OS there is.
I think BSD will always have its place. It is secure for one thing. And nobody wants a GUI on their servers. Running XWindows can create security holes as well.
Consensus is good, but informed dictatorship is better
Yah, now If only I could run Open BSD on a system with more than _one_ processor. =/
-sithEnder
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.
I think its good that organizations such as OpenBSD are taking the initiative to combat DoS/DDoS attacks. I see a lot of companies such as ISS and SecureWorks blowing smoke about "preventing hacker intrusion" when the real threat these days is worms such as Slammer. I really don't know a whole heck of a lot about DDoS attacks, but I've seen a lot of systems crumble under them, even if the os installed on the systems is unaffected. Wonder when Cisco will start doing things like this with IOS? (Unless they already are?) Discussion encouraged.
-===- "Those who would sacrifice freedom for security deserver neither" -===-
This, and other recent, articles about BSD have made me consider giving BSD a test run on one of my computer. It appears to have some interresting posibilities. And it should be worth getting to know better, it could be the right tool (OS) for some types of "jobs".
The problem is always where to start, I assume there is no BSD flavor as easy to install as Mandrake (just to pick one), but then I am a happy user of Debian (2.2) floppy installer. A few hints to start out on, for instance a install/easy of use comparison of the various BSD's would probably be helpful to more than a few readers.
Carbon based humanoid in training.
...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
Anyone mind explaining, or posting some links to pages explaining, what stack smashing is, and why an executable stack stops it?
We're not all l33t haxx0rs here...
"Upon attaching the waterblock to my penis, I began to notice that I know nothing about computers." -- JRockway
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 want it now, but I'd whine if it weren't fully tested. Man, to think I'm doing the "gotta go pee" dance over something like this. I need a life.
We have a lot of single-purpose OBSD boxen here. I like them a lot. Go, team, go!
I never did understand why this particular set of problems was allowed to exist on most x86 UNIX-like operating systems.
It's too bad that they weren't able to completely seperate executable and readable memory, but it's good to see somebody finally taking these problems seriously.
And as a bonus to making the system more secure, these changes will make it easier to debug stack-smashing bugs.
-Mark
Because they're making their OS for profit, and they find they can sell a shitty OS. It costs extra to make it not be shitty, and it's not worth it to them.
Notice that it's apparently worth it to Apple--hence the move to a Unix base. This is OpenBSD; Darwin is based on FreeBSD, right? But maybe somebody will find a way to incorporate these changes into Darwin, or maybe Apple will do it themselves. I would certainly appreciate it if they did.
I found the meaning of life the other day, but I had write-only access.
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
Anyone know how portable these modifications are to other BSDs, notably Darwin?
I found the meaning of life the other day, but I had write-only access.
It's the difference between love of money and love of your job I suppose. People who are more interested in creating a product that THEY want (BSD developers) are more likely to create a product other people will want. People who are creating a product OTHER people want (as in MS developers making products for their managers' current whims) just won't have the heart for it. Of course... an outright disgust and ditrust of your customers helps create a faulty product as well :\
Alito: A vote for Alito is a punch in the eye to put that bitch back in her place!
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
Oh, they certainly can, even though a closed source model is much harder to be secure, given the smaller test, and development base. The problem is, it's simply not a high ENOUGH priority at most businesses. And why should it be, when people buy for marketing schemes, pretty graphics, and "but I just want my $10 modem to work" stuff.
Security isn't just a unix/windows war though, Solaris has had big trouble with security in the past, and so has IRIX. I haven't heard much about AIX, or HP-UX, but likely those machines wont be used for external servers anyway, so it's not QUITE as big a issue.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
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.
I don't think anyone claims OpenBSD is not an innovator. But it really isn't that hard to secure a *nix box from most security breaches. The biggest part is keeping current on patches and staying away from software such as BIND and sendmail. I can still exploit root on an OpenBSD machine with a crappy CGI. If you need to hack the data on a machine, there are low level exploits (though if you have data someone would want to hack, you should be encrypting your filesystems.)
:)
I do admire OpenBSD's approach to software development; it can be called responsible if nothing else. It's just that for volunteers who basically code other *nix OSes, code auditing is not nearly as much fun as porting your OS to a Nintendo.
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
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
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.
1. Linux is better for developers (even some Microsoft developers like to use it as their developing platform - see the whole Roblimo Linux Fest deal)
2. There is more and better software available for Linux then Windows or Macintosh
3. Everything that the casual user needs is available after a 20 minute install process
4. Linux can be more easily managed regardless of overall network configuration
5. Again, and this can't be stressed enough since it is the main factor for management and pointy-hairs everywhere: Linux is far, far cheaper.
If an expensive cost, inflexibility, high risk factor, constant and forced upgrade cycles, and poor memory management makes a good desktop operating system then no, Linux sucks on the desktop.
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.
Secondly, who the hell are you? Stop impersonating me on Slashdot.
--
Theo de Raadt
Founder, OpenBSD project
I guess you could say, we are working on things more significant and important than making sure OpenBSD works on crusty old PDP-8s and Nintendos
:P
Well don't lose sleep over it, I pretty sure NetBSD tied up those loose ends LOOOOONG ago.
Join the TWIT army now!
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. When you install a service you should set up the specific permissions that it requires (this can be made easy - the app, upon install, can recommend the permissions and you can just say, "okay"). If the app tries to do something that it doesn't normally need to do (like access /home/me/mysecretfile), the system should log an access denied message; the Linux kernel right now can't even audit denied access to files! CHUID permissions to deliver mail to people? A much cleaner mechanism is for the mail server to create the files under its own name and give permission to the user to take ownership of the files.
Linux, and Unix in general, tends to have pretty limited access controls. Even with ACL support, the distros still need to ship with restrictive settings and manage them. A lot can be done to provide a framework under which compromises can be limited and can be audited. Right now we don't have that. Without detection and reaction, how do you know that your prevention is effective?
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
OpenBSD, and BSD in general is so much more secure than any version of Windows, it's laughable to even compare the two. This isn't about tightening up their own code, this is about tightening their code to prevent poorly-written 3rd-party applications from becoming launching platforms for attacks against OpenBSD machines. Microsoft's main problem with security isn't 3rd part apps, it's the millions of lines of unsecure and buggy code in highly integrated applications such as Internet Explorer and Windows Media Player.
To compare this to Trusted Computing is like comparing apples and black holes.
-- "Government is the great fiction through which everybody endeavors to live at the expense of everybody else."
Forget about security through obscurity, this is security through paranoia. Sometimes, it is justified.
If you really want security, go and buy OpenVMS!!!!
"Windows was meant to be more of a "user-friendly consumer OS"."
that is no reason for it, that is just an excuse.
Windows is written to meet demand, not to exceded it. It could be secure, but they really don't care.
There starting to care, unfortunatly they would have to do a real redsign from the ground, by people who where experts, and had never seen any other windows code.
Do you think Car companies would care about safety if you were forced to sign a waiver and couldn't sue them? Hell, you'ls be lucky if the brakes worked after a month.
I'd rather hace to do an update once in a while by hand, then an update every couple of months with push button convience.
The Kruger Dunning explains most post on
Adding SMP will make the kernel more complex, and complexity is bad from a security standpoint.
OpenBSD is supposed to be used for network edge devices - firewalls, etc, in which SMP is not required.
If you want a Unix for your desktop - try Linux, or help out testing FreeBSD 5.0.
Its not about Theo "getting it together" ... no SMP is a design decision that has been made.
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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.
Trusted Solaris
andPit Bull from Argus Systems
IIRC, these are more common Un*ces that are patched to provide "capabilities" - that is, instead of the root being the one-size-fits-all user that has enough privileges to get anything done, different kinds of access are broken down so that if a running program getw 0wned, it limits the damage.
Theo's answer to that probably would be, "code it right in the first place and it won't GET 0wned!!!", which is a valid point, the devil (no pun intended) is in the details.
BTW, I first came across EROS comes from Alan Cox in an interview with Robert Metcalfe a few years ago (remember the "Open Sores" series of articles? Great trolling, Bob!), in response to a question of what he thought was going to be the next big thing after Linux. He was impressed with the response (having previously accused Linux-y types of monomaniacal zeal), but it didn't overturn his opinion at the time that Linux was doomed. Oh well. (This comes to you courtesy of the similarly fated Internet.)
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,
I was thinking about this on my drive into work this morning, and I came to the conclusion that what we need to do is to change the C style stack usage to use two or three stacks.
Consider: C uses the stack for three types of information: call/return information, parameter passing, and local variable storage. I assert that this is the cause of most of the stack problems in C - you are using the same thing for three different needs.
Let me discuss each of the three uses in turn. I will use x86 terminology for this discussion because that is the primary architecture used for Linux and because that is what I am most familiar with, but you should be able to generalize my points without much problem.
First, you have the call/return stack. This needs to the be CPU stack so that normal CALL/RET operations work. The only things that should be stored here are the actual return addresses, as well as possibly register saves (esp. for interrupt routines). However, in a unified stack design it is possible for the bad guys to modify the return address. Thus, even in a non-executable stack environment I can still change the return address to point to a function, say exec().
Second, you have the parameter passing stack. Ideally the only thing on this stack would be parameters passed down to the function from the caller. However, in a unified stack design, I can modify this stack to contain data - thus I can create a pointer to the string "/bin/bash" on the stack. With this and with the call/return modification above, I can cause the current function to "return" to exec(), with "/bin/bash" as the arg. Boom. Remote shell.
Third, you have local variable storage. If this space were seperate from the other two stacks, then overflowing a local buffer, while still bad, would not be able to modify the return address nor would it be able to create parameters. Ideally, every subroutine would be given its own sparely mapped local space - thus boundary errors would likely throw a page fault (granted, the cost of setting such a mapping up for each subroutine call would be prohibitive, so it is unlikely to happen without some form of hardware acceleration. Perhaps a low/high limit register could be added to the various index functions, such that an access relative to EBP, ESI, EDI would fault if it went out of range.)
However, consider just seperating the stack into three areas, widely seperated. ESP would point to the hardware stack. EBP to the local storage area, and ESI to the parameter block (with EDI pointing to "this" for C++). Now, a bad programmer has a buffer in local storage and doesn't range check it. A would-be exploiter still cannot modify the return address nor can he modify the parameter stack. The most he could do would be to hose the local variable storage (granted, that might still allow him to corrupt the local vars for some other function and perhaps get an exploit that way, but it would be even more difficult).
Granted, to do what I just suggested means throwing out *all* standard libraries, tools, compilers, and so forth - I am not actually suggesting that the x86 family do this! However, for new architectures like Sledgehammer et. al, this might be the time to make such a break.
www.eFax.com are spammers
SMP simply is not a requirement for OpenBSD's niche. Besides, if you want SMP in OpenBSD, there's nothing to stop you forking it and building your own...
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.