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
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
Say goodbye to JVMs which do on the fly instruction creation. Can this OpenBSD page protect mumbo jumbo be set on a program by program basis?
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.
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
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.
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.
Theoretically, a capabilities-based OS like EROS would be even more secure than OpenBSD, if the implementation was as careful. Of course, the same tradeoffs that OpenBSD makes would be even more extreme (application support definitely, performance probably I would think)
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."
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.
"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
It would also be lovely to see the tool which manages all this unify all the ACL-like aspects of the system into a single interface. Firewalls, filesystem ACLs, and privilege delegation are all remarkably similar, it'd be great to be able to define them selectively in groups (I think SELinux calls them "contexts") and confer them to various processes. Daemons can bind to ports, but not regular users? Easy: set the firewall ACL policy to deny, then grant the "daemon" context an exemption. Then tie in other useful privileges, like the ability to write to /var/run and send messages to syslogd. All these things are obviously related conceptually, but currently you'd need 3 tools to do it all (I don't think it's possible to regulate syslogd access this way, period, but I'm being optimistic and assuming it is).
Unfortunately, from what I saw of SELinux when I last used it, all this is some time off... especially the part where it's easy to administer and use. But to end on a positive note, there are a bunch of people who recognize this problem and are working hard to correct it.
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.)
Just had to comment on this line:
FreeBSD clings too much to traditional Unix.
Heh.
And what did you expect it to cling to? Traditional VMS? Don't forget that FreeBSD IS UNIX. FreeBSD is a direct descendent of the code from the original 4.4BSD. THIS IS UNIX. Love it or leave it.
(Personally, I love FreeBSD and 5.0 kicks major ass. Linux is cool, but I use Gentoo, which is arguably more BSD-like than any of the other distros except for maybe Slackware.)