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."
Slowdown? (Score:4, Informative)
new method? (Score:4, Informative)
Re:new method? (Score:4, Informative)
Hm... gotta reply to myself (Score:5, Informative)
Re:My Windows XP has heap protection! (Score:5, Informative)
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.
Re:In related news, GCC 4.1 stack protector (Score:4, Informative)
Also Worth Mentioning (Score:5, Informative)
Re:new method? (Score:5, Informative)
This new feature from OpenBSD is the use of guard pages and the immediate freeing of memory. In essence this means that both bad programming and exploit attempts are much more likely to result in a core dump then some unidentifiable and non reproducible corruption or a working exploit. Many people consider that a good thing because it will result in bugs being found in userland applications that would have otherwise stayed unnoticed. So even if you don't use OpenBSD yourself this is helping your system becomming more secure and better. And if you are running OpenBSD there is o need to worry too much about the stability of this feature, it was actually enabled shortly after the 3.7 release and has been in every snapshot on the way to 3.8.
And I have to agree with the author that the best thing is that we get all the goods without ever having to switch them on!
Not the same thing (Score:1, Informative)
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.
Re:cool (Score:2, Informative)
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. :-)
Re:Could this help Gnome? (Score:3, Informative)
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.
Re:Slowdown? (Score:5, Informative)
http://www-128.ibm.com/developerworks/java/librar
Malloc is slow. Per studies, 20-30% of CPU time wasted on memory management.
I haven't seen that level of retardation in JVM's since... oh... 1996?
But yeah, keep thinking you can do it better. Whatever. In the meanwhile, the rest of the world moves on.
Re:new method? (Score:5, Informative)
They also didn't need the per-page execute bit to do it. You need a fairly new machine to get the protection, but my 486 firewall has it. They also have stack protection, which is helpful because even if the heap and stack aren't executable you can overwrite return addresses or pointers to functions, and have them point to existing code that can be tricked into doing something malicious.
Re:Wrong solution for solving heap problems. (Score:3, Informative)
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.
Re:This is why I couldn't use OpenBSD exclusively. (Score:5, Informative)
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.
Re:Slowdown? (Score:3, Informative)
Its use dates back to the first GC'd langauge, LISP, and was a common way to reduce garbage generation.
Re:Hope (Score:4, Informative)
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.
Re:Wrong solution for solving heap problems. (Score:3, Informative)
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 [wikipedia.org]
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.
Re:Slowdown? (Score:3, Informative)
I've heard of pooling but was under the impression that you were mallocing several memory allocations at once, but that the pieces of allocated memory were assigned to particular uses.
That is basically what you just described - malloc std_length * count. Allocate out of this pool preferentially.
The primary benefit of this was to perform one malloc instead of N mallocs for N different memory assignments.
This performs 1 + N*M(1-hit_rate) allocations instead of N*M allocations, which is generally really nice.
Re:This is how Electric Fence works. (Score:1, Informative)
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 !