Heap Protection Mechanism 365
An anonymous reader writes "There's an article by Jason Miller on innovation in Unix that talks about OpenBSD's new heap protection mechanism as a major boon for security. Sounds like OpenBSD is going to be the first to support this new security method."
Re:cool (Score:4, Insightful)
Just like...
Windows 95 was more secure than Windows 3.1
Windows 98 was more secure than Windows 95
Windows NT was much more secure than Windows 98
Windows 2000 was the mother of all security
Windows XP, this time we got it right
Windows XP SP2 this time we really really got it right, promise, cross my heart and hope to die
Windows 2003, most secure server OS ever built!
Windows VISTA, even better than the worlds best system ever built, this time ill put my mother up here on this 100 fot pole and if im wrong may she fall down into that pit of crocodiles!
Until i have a real life experience of good Windows security i will tend to think back and remember all the former promises that have gone down the drain. Today you expect Microsoft to promise things that arent really true.
Totally wrong (Score:2, Insightful)
Re:new method? (Score:3, Insightful)
First, their system is working properly. Their OS is working, and their application is working. And then SP2 comes out, and they install it. And their application stops working.
Who are they likely to blame? Microsoft of the creator of their application? They'll look at what changed, and decide that Microsoft is to blame. And if this application is important, they'll even back out SP2 to make it work again.
Re:Sacrfice useability? Nice idea , won't work. (Score:5, Insightful)
The reason is very simple: There will always be some applications where the security of the system is a paramount point. Where it does have to do with the application. OpenBSD caters directly to those people, and those applications.
Now, you are right, this means OpenBSD is likely to never get as large a following as Linux or even FreeBSD, but they honestly don't care. They are making a system that fits their goals, and security is among the top goals.
This actually allows security to spread: Once these changes are on a 'major' system, applications start to be ported to work with them, which means the changes can be ported to other systems.
OpenBSD is a security testing ground. If it's features get in your way, you use a different system. This won't be the first time that advice will have been applicable.
Unnecessary when using languages that solve this p (Score:3, Insightful)
It is therefore, in my opinion, less optimal (from a security perspective) to use something like "C" for a complicated app like sendmail, web server or secure shell daemon (sshd) than it is to use a language like "C".
Re:OpenBSD at the cutting edge on security (Score:4, Insightful)
Doesn't seem so. The new malloc and mmap behavior will tend to cause buggy memory allocation code to segfault rather than allowing various sorts of stupiness or nastiness.
Finally Locking the Door (Score:5, Insightful)
After decades of these problems, and known techniques already applied in Computer Science, its surprising that we're only now seeing these techniques deployed in popular OS'es like OpenBSD. Hopefully the open nature of OpenBSD and other OSS OS'es will see them tested for winning strategies quickly, and widely adopted.
Re:Microsoft Windows? (Score:2, Insightful)
It certainly could be implemented, but it would have the slight drawback that a huge proportion of apps would stop working.
It's going to break a lot of stuff on OpenBSD as well, but because of their audience they can get away with e.g telling you not to run Apache because it's insecure. Also, the OSS apps that break because they assume a specific memory management model will get fixed. No-one is going to be able to fix Windows apps except the developers. And if they even bother they will just expect you to buy the new version.
And you seem to be saying that implementing this one feature on Windows will make it more secure than $OtherOS. I initially thought you might be trolling, but I've decided to give you the benefit of the doubt and just assume that you either know nothing about security or are making a lame attempt at humour.
Re:OpenBSD at the cutting edge on security (Score:3, Insightful)
I don't see how that encourages writing `sloppy memory management'. Nobody wants an application that crashes. (Granted, it's correct for an application to immediately exit when it's in danger of doing damage to something, but to an end user, they don't want their application to crash.)
Perhaps if somebody is explicitly writing their application to be secure, they could worry less about their memory management and assume that the OS will keep them honest (as it should) but ultimately, an application that crashes isn't very useful. And most end users don't care much about security anyways (though if they're using OpenBSD, odds are that they care about security more than most) and would much prefer something that doesn't crash.
Theo seems to think so. If you disagree, either disable it (it sounds like it's at least somewhat configurable, and even if not, you do have the source), or use another OS.Re:Intron == heap protection (Score:3, Insightful)
You're still correct. It is heap protection in an evolutionary way. Heap protection on computers seeks to safeguard the data as it is. Junk DNA accepts that things are going to get corrupted and seeks to make it statistically less likely for the important parts to get corrupted.
Thanks for that train of thought.
Re:OpenBSD at the cutting edge on security (Score:3, Insightful)
"hey, it might do something strange every once in a while, but at least it keeps running and doesn't crash, so the code is 'good-enough'".
I think Theo is doing entirely the right thing by killing badly written apps rather than letting them do bad things to the system. It's much more likely to make people fix bad code than the current system.
Re:cool (Score:1, Insightful)
None of these problems occur on any other OS. If one of the others were instantly as widely used as Windows, yes there would be more security issues discovered but not as many as are routinely discovered under Windows.
Having the OS closed source also raises security concerns as the binaries are much harder to verify as opposed to the source code available elsewhere (not just Linux source, but the BSDs and open Solaris).
Microsoft could do themselves a favor by simplifying the base OS (as they do occasionally though features creep in) and providing better default analysis tools -- hell, just buy the Sysinternals tools and bundle them!
Comment removed (Score:4, Insightful)
Re:This is how Electric Fence works. (Score:3, Insightful)
I think that's exactly the problem though. There are users out there installing applications they found somewhere, by somebody who may or may not have bothered to use a good debugger. This will prevent those unknown bad apps from fouling up the system.
I'm still on OpenBSD 3.7. I haven't tried the 3.8 builds, but I'm hoping the overhead from this won't be too bad.
Re:For Real Security (Score:2, Insightful)
Re:Slowdown? (Score:5, Insightful)
Interesting paper - thanks for the link.
However I find the conclusions given a bit dubious. For instance the claim that allocations are "free" is somewhat dubious - garbage collecting languages put all of the work on the back-end, giving the illusion of a free front-end (whereas non-GC languages put the hard work on the front-end). Yet for every object you create on the heap that is more work the heap walker has to do each GC to detect orphaned objects - a non-trivial task. It then has to free all of those objects, and because of the "free" allocation it has to move all of the objects and rebase every object pointer in the application. It doesn't take a genius to realize that is a signficiant task in an application of a real-world size.
I think the proof is in the empirical proof - how many high performance memory intensive Java applications are there?
Re:Intron == heap protection (Score:3, Insightful)
Just being a "dummy target" seems like an inefficient use for extra DNA. I would have expected something along the lines of ECC like reed-solomon coding to have evolved. Kinda shoots down the "intelligent design" theory too, unless you can accept that God is an amateur at this stuff.
Re:Slowdown? (Score:5, Insightful)
PS: A quick look at some fast Java code. (It is a bit dated but gives you some idea what I am talking about.)
Hmm ... that's a little archaic. The page complains about Java performance in JDK 1.1, and appears to be based on a site (http://www.cs.cmu.edu/~jch/java/optimization.html [cmu.edu]) that hasn't been updated since 1998.
Re:Slowdown? (Score:3, Insightful)
The issue with GC vs. non-GC languages is that GC pushes all that GC stuff to the back end, but ask yourself, what if you never have to collect the garbage? The whole question lies in, if we wait until the back-end to clean everything up, will we gain any time? Considering that you spend less time on important non-transient things with GC, and potentially more time on very transient things, while you spend about the same time on both in non-GC, the question is How transient is your memory? Of course, the less transient your memory is, the less often you'll have to reallocate space for it in the non-GC case... so...
Re:This is how Electric Fence works. (Score:4, Insightful)
The OpenBSD allocator already has revealed a number of software bugs (in X11, in ports, they lurk everywhere). Some of the bugs found were years old. Thats the point of the testing process in the OpenBSD release cycle.
I think you're missing the point behind the integration of these technologies into OpenBSD. The idea is that they are always on, with a performance hit that is acceptable that your day-to-day programs can be protected, and most crucially, used under them. Not sitting in a debug environment getting limited regressions and unit tests that the particular programmer felt like writing (and if I want that, I run it under Valgrind, which has a near-miraculous tendency to find lurking bugs).
And considering them in isolation is also dangerous. When you combine the address randomization, W^X, heap protection, propolice canaries and local variable re-ordering, you're left with a system that has accepted a reasonable performance hit in return for a large amount of protection against badly written code. Sprinkle in regular audits, timely releases every 6 months to keep our users up-to-date on stable systems, and a 'grep culture' to hunt down related bugs in the source tree when a bug does strike.
As others have pointed out, other "hero projects" have stuck bits and bobs into their respective distributions. But how many have had the discipline to follow through, maintain and integrate their patches, test the fallout and release a complete OS with thousands of third-party packages year after year... probably only Microsoft, but the first thing they do at the sign of incompatibility is to turn the protection off. Oh well
Re:new method? (Score:3, Insightful)
Ultimately, think of Grandma. She fires up AOL, then her computer tells her that she needs SP2. She goes `ok' and many hours later, SP2 is done, and her {insert program useful to grandma here} application no longer works. She's not likely to blame this on the creator of the program -- she'll blame it on either Microsoft or AOL. (After all, grandma is no dummy. She knows that the program didn't change -- only Windows did. And perhaps AOL made it do it.)
It must really suck doing AOL tech support :)
Re:Wrong solution for solving heap problems. (Score:3, Insightful)
Permenantly dark goggles -- Java, etc
Goggles that tint when bright light happens -- C
The argument "C is insecure, we should use [insert odd language here]" is like saying, "Goggles that auto-tint are bad because they're not dark all the time, and you could see a bright flash."
The argument I made would be more like, "The auto-tint goggles are better because they take the basic need -- you have to see -- and allow that, but still protect you from the blinding flash of welding light when needed by cutting your vision off at that moment, a necessary evil some of the time."
I suggest you don't make retorts to peoples' comments unless you actually know what you're talking about.