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."
other OS have had heap protection mechanisms, even one from Microsoft.
Ok, I've posted hastily, thus creating a bit of an half-assed post. They use more techniques (random address allocation, immediate free-to-kernel), still not revolutionary, but indeed worth mentioning. My bad.
This is more. It looks like they are adding extra 'tripwire' pages to the heap, so if an attacker manages to write to part of the heap they shouldn't, there's a good chance they'll hit a tripwire and be detected.
There are patches available at http://www.trl.ibm.com/projects/security/ssp/ for 3.4.4 and 2.95.3
This presentation (by Theo de Raadt) gives a good overview of the security features in OpenBSD (beyond what's already outlined on the OpenBSD security page). It covers W^X, random stack displacements, random canaries to detect stack smashing, random library base addresses, random addresses for mmap and malloc operations, guard pages, privilege revocation, and privilege separation. One thing it doesn't cover is systrace.
Please correct me if I got my facts wrong.
What you are talking about is the no-execute page protection. Unix has had this for most of it's existence. Until the last few years it didn't work very well on Intel systems due to hardware limitations (if you can read a page it is executable). The workaround involves using segmentation but it was very ugly. Recent processor updates have included the ability to set a no-execute bit which works even if the page is readable. Both OpenBSD and Windows (and Linux) support this already.
The _heap_ protection is additional. There are various attacks based on malloc()ed memory overflows which are thrwarted by use of non-readable memory barriers and better protection of the internal malloc datastructures. The no-execute stuff isn't really related, though I believe OpenBSD already disallows execution of malloc()ed memory by default.
For about the 35,348th time: no, no they don't. IE has nothing to do with the kernel. Go and learn what a kernel is. Hope that helps, have a nice day. :-)
I don't know if GNU malloc uses mmap() or brk() for its allocation, but in both cases small memory chunk that the user allocates are taken from bigger, contiguous blocks of memory.
It uses mmap() for big allocs (IIRC the threshold is 4 MB) and brk() for smaller ones.
There would be one solution, and that's using different arenas, or memory regions for allocation. For instance every window might have its own allocation region, so when you close the window/document, the memory BLOCK is freed.
Something like memory pools, used e.g. by apache portable runtime, gcc, and whatnot. Or the hierarchical allocator used by samba..
I really wish Java apps, Cocoa apps, and other (Mozilla) would do this, as they seem to suffer from this fragmentation problem, only increasing their memory usage, even after closing all documents/windows etc.
Actually, Java being garbage collected and not having "raw" pointers can avoid fragmentation by repacking heap memory. Of course the JVM must still use malloc() or mmap()/brk() directly to get the memory from the OS.
1. OpenBSD already makes use of NX-bit protection (they call it W^X).
2. OpenBSD previously implemented stack protection (propolice + other stuff).
3. OpenBSD even implements W^X on non-NX-bit i386 through other techniques.
The last point is important since most i386 machines don't have the NX-bit, and that will be the case for many years to come.
You gotta remember, the project doesn't do it for outsiders, what they do is for themselves. They want security and are willing to pay performance and ease of use to get it, it's like a mantra for them, never take the path of least resistance.
If this looses like 5 or 10 percent of it's performance on my machines I won't mind, it's another layer of protection and I like having it and am fine with the cost, faster hardware isn't that expensive. If something I run crashes, I will report to the people that wrote it, telling them that I found a problem that was found by OpenBSD's malloc, maybe they'll even devote an old test box to checking for bugs on it.
If OpenBSD was trying to be a Linux distribution then we'd not have most of the good stuff that makes OpenBSD unique.
I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
There have existed functions in Windows and Linux for a long time that mark a page as executable. Even though Linux or Windows never really enforced this to be set when executing data, it was required by specification.
Now that they're enforcing the specification, people complain that it broke.
Hey, PearPC was written before they enforced the specification, and Sebastian Biallas had the brilliant notion to actually follow the spec, and mark things as executable. Thus, when SP2 came out, PearPC worked fine.
Usually things break when moving to a newer version because some area of the spec wasn't very heavily stressed, and people writing code that just works (not as in, it works, but as in barely works,) thusly never really bothered shooting towards the spec. Then when the spec is enforced, they get all upiddy claiming that it breaks their app. Their app was broken to begin with, the previous implementations that you were relying on just didn't care.
For instance, when libc 5 (I think, don't hawk me about versions, if you know the correct versions, then please correct me, but I'm working off of a poor memory of the version numbers) came out, it enforced against passing a NULL file pointer. Before hand some people had hacked their code such that if an open failed, and returned a NULL file pointer, they didn't care or print an error message. They just kept going, since it would just waste CPU cycles, as nothing would get outputted or read from the file. It was silently gracefully failing for them, and they used that.
Then libc 5 comes out, and they break this silent graceful failure, and started reporting errors, or crashing when you passed them a NULL file pointer. People yelled and bitched, because they broke their app. But remember, THEIR APPS WERE BROKEN IN THE FIRST PLACE.
That's why I don't like people griping about "blah blah upgrade broke my app". Unless you can state that your app was built to spec from the beginning, then that upgrade didn't break your app. It was broken to begin with. The new upgrade just showed you how it was broken.
I am unamerican, and proud of it!
The solution shown does not mention usage of the NX bit (which is i86 specific).
Actually, x86 is one of the last into town with "NX bit" functionality. POWER (and PPC I guess), PA-RISC, Sparc, Alpha, etc. on the big-iron has had this feature as a standard part of their architecture (along with the OSes that run on them) for bloody ages now... on those CPUs, even Linux has had hardware support since before whenever x86 got NX support.
http://en.wikipedia.org/wiki/NX_bit
Although this can stop execution of arbitrary code in areas of memory that aren't meant for it, you're still going to be vulnerable to corruption of memory and make the software behave in unintended ways. The problem is that the Operating System can't tell the difference between a memory pointer that has stepped outside the malloc'd space it was intended to address and into an adjacent one, or two legitimate pointers behaving nicely.
Adding the guard space will definately help, as will unmapping memory. OpenBSD hasn't exactly been known for its high performance; people use it for security and peace of mind. Additionally, they made mmap() return random addresses, which is very cool indeed.
doesn't anyone think that it is time to stop using C?
C is not used for building web apps, so what are you talking about?
Everybody knows C is the right tool for some jobs, Java/Perl/Ruby/etc for others.
In the right hands C can be just as secure and has the potential to be much faster than most of the alternatives.
But yet, since they commited this protection on cvs HEAD, OpenBSD's devs have found many bugs on many heavily used components (including x.org, kde, gnome).
For sure, those bugs should have been caugth by Efence: theyre may still be lazy devs, around there, that don't take full advantage of Efence checks. So here my conclusions:
The keywords here are "system wide, by default, all the time", "no huge slowdown" and "more exposure".
So yes, Efence does this, and better. And we are all are very thankful to you for this great lib. But having more code (all the code running on OpenBSD) exposed to a similar protection, and having it exposed for a longer time (as long as it's used on OpenBSD, basically) isn't a bad thing.
People shouldn't think of OpenBSD protections and Efences as competitors, but rather complementary tools: Efence has more granularity, people should continue to use it. OpenBSD gives more exposure. At the end of the day, having both available results on having better softwares on the OSS world. All the world is pink !