Slashdot Mirror
Heap Protection Mechanism
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."
"What do you mean? Windows Vista will be more secure than Unix. j/k"
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.
HTTP/1.1 400
What they restrict here, is extremely shitty programming. What's the point of allowing accessing memory areas out-of-bounds? Fewer crashes, because the system does not notice them? This is a very bad idea. If you don't know how to handle arrays and you don't know any other means to restrict yourself from doing something stupid, OpenBSD shows the best way to do it (as last instance).
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.
Actually, for OpenBSD, it will work. And has.
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.
'Sensible' is a curse word.
Languages like Lisp, Haskell, Scheme and ML allow you to avoid buffer and heap overflows (assuming the language implementation is correct).
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".
http://www.thebricktestament.com/the_law/when_to_
Won't this crutch actually tempt people to write sloppy memory management because "the heap manager will catch it?"
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.
I'm surprised that modern heaps still put writable data segments adjacent to executable code segments. Self-modifying code is rare enough that all code should be in read-only (except by privileged processes, like the kernel which sets it up and tears it down) segments, except when a process has privilege to write to its own code segment. Then its code segment should be a data segment, with other security features applied (that are too expensive to apply to every code segment). Generally then, segments are either writeable or executable. Data segments could still get overwritten, which could put unsafe values in unexpected variables (like "write to that file" instead of this file). But at least those insecure operations are limited to the operations programmed into the code, not arbitrary new code inserted into executables by buffer overflows.
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.
--
make install -not war
Could this technology be implemented in the Microsoft Windows systems to be more secure than Linux?
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.
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.In some cases introns serve a known purpose in indexing for the enzymes which work with DNA. Junk DNA is the stuff with no known purpose at all.
:)
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.
fast as fast can be. you'll never catch me.
"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.
It's not that MS Windows (2000K or later) can't be secured, it's that Microsoft has strange defaults and in some cases makes it un-necessarily complex to secure the system. The defaults and the excessive features that are enabled that are security problems by themselves are well documented. Add to that the tools included with Windows are weak, incomplete, and often wrong intentionally and you have problems from the start.
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!
Who is "not giving back?"
Feel free to download all of their source code before complaining.
If you don't like it, don't use it, even though I'm sure you too benefited from some security fixes that originated with OpenBSD.
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.
From the examples in the essay, you could easily make the case that for real security use good code.
Who ordered that?
Malloc is slow. Per studies, 20-30% of CPU time wasted on memory management.
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?
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.
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.
When information is power, privacy is freedom.
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 ) that hasn't been updated since 1998.
Well the same issue exists with Copy-on-Write. COW implementations give an impression of faster copying, because they back off all the copying until the first damage to that information. Turns out that in some cases you don't need to make an actual fresh copy in every situation, and that sometimes, you just copy it to use it, don't damage it then just return. In those cases COW gains you time. Since you only copy when you must. You just have to deal with blocking during the first write to the copy. (You would have waited anyways during the copy, you just shift were it's at.)
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...
I am unamerican, and proud of it!
I don't think the BSD allocator will reveal more software bugs unless the programmers have not tested with Electric Fence.
:)
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
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 :)
Actually, the correct analogy would be:
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.
Support my political activism on Patreon.