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."

Comments

Slowdown?

[(1 -sqrt(5))*(2**-1)]

Continues Theo,

A number of other similar changes which are too dangerous for normal software or cause too much of a slowdown are available as malloc options as described in the manual page.

Id est, they stopped before reaching a Java-like retardation.

Re:Slowdown?

[Anonymous Coward]

Ho hum.

http://www-128.ibm.com/developerworks/java/library /j-jtp09275.html

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.

new method?

[iggymanz]

other OS have had heap protection mechanisms, even one from Microsoft.

Re:new method?

[Intron]

ISTR that MS tried doing immediate free and it broke some programs that depend on the memory still being sround after being freed, so they made it optional. Sounds like OpenBSD is playing hardball here.

Re:new method?

[JohanV]

You mean the Data Execute Protection from Microsoft? OpenBSD has had that for a long time already, only they named it w^x.

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!

Re:new method?

[ArbitraryConstant]

"You mean the Data Execute Protection from Microsoft? OpenBSD has had that for a long time already, only they named it w^x."

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.

Hm... gotta reply to myself

[archeopterix]

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.

Re:My Windows XP has heap protection!

[jcupitt65]

The MS thing is just support for no-execute: the bit that says that this page is only code and not data and you shouldn't try to run anything in here. Everyone has supported this for ages.

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

[rehabdoll]

There are patches available at http://www.trl.ibm.com/projects/security/ssp/ for 3.4.4 and 2.95.3

Also Worth Mentioning

[RAMMS EIN]

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.

Re:This is why I couldn't use OpenBSD exclusively.

[Nimrangul]

But they don't care, they're not trying to be FreeBSD or a Linux distribution, they're trying to be OpenBSD and a part of that is not letting people's perception of optimum performance get in the way of doing what is right by them.

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:Hope

[Krach42]

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.