Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Heap Protection Mechanism

Hemos posted more than 8 years ago | from the protecting-ourselves dept.

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

cancel ×

365 comments

Sorry! There are no comments related to the filter you selected.

Slowdown? (4, Informative)

(1+-sqrt(5))*(2**-1) (868173) | more than 8 years ago | (#13703959)

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? (0)

Anonymous Coward | more than 8 years ago | (#13704083)

What are you talking about? Java is the answer to every problem.

Re:Slowdown? (-1, Flamebait)

Listen Up (107011) | more than 8 years ago | (#13704256)

Proving once again that you and 99% of the Slashdot crowd have no real clue what you are talking about.

Trying programming in Java sometime outside of a website applet, kid, and maybe you will learn something.

Re:Slowdown? (0)

Anonymous Coward | more than 8 years ago | (#13704369)

If I wanted an interpreted language, Id use QBasic!!

Re:Slowdown? (0)

Anonymous Coward | more than 8 years ago | (#13704503)

the original post was the troll, really please stop kicking Java around

OpenBSD Goals (2, Interesting)

RAMMS+EIN (578166) | more than 8 years ago | (#13704490)

Yep. After all, the goal of the OpenBSD project is not simply to be the most secure operating system ever. The goal is to provide the best security, along with a number of other goals, such as running Unix software, achieving good performance, and providing a good (according tho the stated goals even "the best") development platform.

cool (1, Funny)

chrisxkelley (879631) | more than 8 years ago | (#13703968)

now unix will be more secure than all... well, again.

Re:cool (0, Flamebait)

mysqlrocks (783488) | more than 8 years ago | (#13704001)

now unix will be more secure than all... well, again.

What do you mean? Windows Vista will be more secure than Unix. j/k

Re:cool (3, Insightful)

miffo.swe (547642) | more than 8 years ago | (#13704099)

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

Re:cool (2, Interesting)

Iriel (810009) | more than 8 years ago | (#13704285)

Then again, while I'm not defending Microsoft, here's my take on their 'security':

Yes, plenty, and maybe even most of their promises about being a generally secure system are complete and utter rubbish. However, I'm willing to bet that each of their OSes are more secure than the last one. The problem is that they still leave plenty of holes open when they do things like (to point out the landmark example) weld the web browser to the kernel. I know that most people crack windows because it's easy, but while I may be wrong on this, I think people will continue to spend thier efforts on Windows even if their security was (competely hypothetically) top-notch only because of the bad reputation that precedes them.

I'm not saying that Windows is secure or that it ever will be. However, their security has improved, regardless of how poorly. The last reason on the list to crack Windows (in my opinion) and possibly the strongest reason is that they have a history of poor security. I think script-kiddies will pour ANY amount of effort into destroying any version of Windows just to keep that idea alive.

As much as I love Linux, I really doubt that any one distro (like RedHat for example) would be able to keep their system as secure as it is now if they were the entire world's information security scapegoat as MS is now. (PS, yes I know that MS does, mostly deserve the title they hold)

(I'm not a security expert, nor am I claiming to be, so if you think I'm wrong all I ask is that you not 'correct' me with a torch ^_^)

Re:cool (2, Informative)

resiak (583703) | more than 8 years ago | (#13704528)

they do things like (to point out the landmark example) weld the web browser to the kernel.

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:cool (1, Insightful)

Anonymous Coward | more than 8 years ago | (#13704617)

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!

Re:cool (0)

Anonymous Coward | more than 8 years ago | (#13704295)

You realize that "j/k" stands for just kidding, yes?

new method? (3, Informative)

iggymanz (596061) | more than 8 years ago | (#13703973)

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

Re:new method? (3, Informative)

Intron (870560) | more than 8 years ago | (#13704049)

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? (1)

fitten (521191) | more than 8 years ago | (#13704076)

ISTR that MS tried doing immediate free and it broke some programs that depend on the memory still being sround after being freed,

Sounds like those programs were broke from the start.

Re:new method? (2, Insightful)

dougmc (70836) | more than 8 years ago | (#13704163)

Sounds like those programs were broke from the start
Perhaps, but look at it from the user's perspective :

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:new method? (2, Interesting)

afidel (530433) | more than 8 years ago | (#13704292)

In the three cases we ran into when I was a consultant last year we placed the blame squarely on the shoulders of the vendor with the foobar product. They were coding in an unsafe manner to an undocumented API, it was 100% their fault. Now a naive home user with no real computer savy might blame MS, but when you look at the tradeoffs it seems like the security cleanup was good for the entire computer using public, even if a few people did have an app or two broken.

Re:new method? (1)

zootm (850416) | more than 8 years ago | (#13704324)

Unfortunately, this is a perspective that MS can't really afford to have, although they probably want to.

Intron == heap protection (2, Interesting)

hey (83763) | more than 8 years ago | (#13704151)

I don't know if it was on purpose but your sig -- which mentions Intron [wikipedia.org] (aka Junk DNA) is very apt.
OSes can put Intron between Exon (useful DNA -- useful stuff on the heap) to
detect badly behaving apps!


In other words, so-called "Junk DNA" may actually have a use...
HEAP PROTECTION ;-)

Re:Intron == heap protection (2, Insightful)

SilverspurG (844751) | more than 8 years ago | (#13704429)

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. :)

Re:new method? (5, Informative)

JohanV (536228) | more than 8 years ago | (#13704300)

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

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!

Hope (4, Interesting)

Anonymous Coward | more than 8 years ago | (#13703974)

Let's hope it's not as broken as Microsoft's attempt [maxpatrol.com] in SP2.

But why did it take so long to implement?

Re:Hope (1)

slavemowgli (585321) | more than 8 years ago | (#13704197)

Maybe the reason is precisely that they tried to make sure it's not as broken as Microsoft's attempt in SP2.

Re:Hope (1)

pla (258480) | more than 8 years ago | (#13704360)

Let's hope it's not as broken as Microsoft's attempt in SP2.

In fairness, I don't know that we can really blame Microsoft for that one...

XP's memory protection works just fine (assuming the CPU supports NX pages) - The concept takes almost no thought to implement. The problem, however, arises from 99.999% of existing software not caring in the least about the separation of code and data. Usually that doesn't cause any problems, but when a "clever" (I put that in quotes as the bad-idea-of-the-day, but really, it does count as clever - Just not safe in a multitasking/multiuser/networked machine) program tries to execute something in its data, suddenly you have a problem.

As an aside, I have to wonder how functional languages such as Scheme or Tcl work at all with memory protection enabled. Not only do they tend to lack explicitly separate data and code, but they more-or-less depend on the ability to construct functions dynamically, as data, and then invoke them as code.

Re:Hope (1)

arkanes (521690) | more than 8 years ago | (#13704606)

The NX flag is basically opt-in, you can request pages that aren't marked with it. In an OS that flags everthing as NX by default, you'd need to rebuild your application (although XP allows you do disable NX on a process by process basis). The point of NX isn't to prevent stuff like Scheme working, it's to prevent exploits or accidents.

OpenBSD at the cutting edge on security (3, Interesting)

Sv-Manowar (772313) | more than 8 years ago | (#13703997)

Kudos to the OpenBSD folks for being at the cutting edge, in terms of implementations of these security features. Where they lead, surely others will follow and we'll be seeing this feature become commonplace. As their focus is security, its understandable that they lead more incentives in these areas than more mainstream Linux distributions.

Re:OpenBSD at the cutting edge on security (1, Interesting)

Anonymous Coward | more than 8 years ago | (#13704034)

I'm quite surprized to see Theo doing this.

"... in other words, it doesn't matter WHERE you shift the buggy code."

                          --Theo de Raadt

Won't this crutch actually tempt people to write sloppy memory management because "the heap manager will catch it?"

Is the performance hit really worth it?

Re:OpenBSD at the cutting edge on security (3, Insightful)

failure-man (870605) | more than 8 years ago | (#13704238)

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.

Re:OpenBSD at the cutting edge on security (2, Insightful)

dougmc (70836) | more than 8 years ago | (#13704302)

Won't this crutch actually tempt people to write sloppy memory management because "the heap manager will catch it?"
Well, it'll catch it ... and the application will immediately crash.

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.

Is the performance hit really worth it?
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:OpenBSD at the cutting edge on security (2, Insightful)

LurkerXXX (667952) | more than 8 years ago | (#13704535)

You mean it will encourage sloppy coding more than the current system?

"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:OpenBSD at the cutting edge on security (2, Funny)

fireboy1919 (257783) | more than 8 years ago | (#13704074)

than more mainstream Linux distributions

I know it seems strange...but OpenBSD isn't a Linux distribution at all.

I know its hard to wrap head around. Its one of those things you just have to accept. In addition:
-deep down, cows are not people too. So you can eat 'em, I guess.
-neither are cats or dogs. So don't force them to wear clothing.
-neither is information. So it doesn't care about being free or anything else.
-"Windows" is somehow both an operating system and a Window manager. You're not supposed to consider them separate things (wierd, isn't it?)
-Wearing a tampon with wings will not give you the power of flight.

Hopefully I've cleared up a few issues for you. :)

Re:OpenBSD at the cutting edge on security (1)

'nother poster (700681) | more than 8 years ago | (#13704109)

I read the grandparent post as saying that Linux was more mainstream than OpenBSD, not that OpenBSD was a version of linux.

Re:OpenBSD at the cutting edge on security (1)

fireboy1919 (257783) | more than 8 years ago | (#13704287)

You can certainly read it that way if you like. You wouldn't be conveying what that sentence did, though.
As their focus is security, its understandable that they lead more incentives in these areas than more mainstream Linux distributions.

In this, the word "more" describes "Linux distributions." As it is a comparison, it also refers back to the subject of the phrase. The subject being "they," a pronoun which refers to "OpenBSD." This comparison also draws them into the same category because its comparing a single element to a collective.
To clarify, let me simplify this sentence, excluding all (mostly) superfluous modifiers:
"OpenBSD is more secure than more mainstream Linux distributions."

So...if open BSD is more secure than other, more mainstream Linux distributions, then it must be one of the lesser Linux distributions. Read more. You'll catch the subtle points more often.

Re:OpenBSD at the cutting edge on security (0)

Anonymous Coward | more than 8 years ago | (#13704587)

Ok. You read it your way, I'll read it mine. I read "more mainstream" as the modifier of "Linux distributions" implying that Linux is more mainstream than Open BSD, not "more" as a modifier of "mainstream Linux distributions" implying OpenBSD is Linux.

Re:OpenBSD at the cutting edge on security (1)

richy freeway (623503) | more than 8 years ago | (#13704192)

Wearing a tampon with wings will not give you the power of flight.

I'm no female, but a tampon with wings sounds mighty uncomfortable!

Re:OpenBSD at the cutting edge on security (0)

Anonymous Coward | more than 8 years ago | (#13704225)

Depends on where they flap.

Re:OpenBSD at the cutting edge on security (1)

ksheff (2406) | more than 8 years ago | (#13704534)

Wearing a tampon with wings will not give you the power of flight.

Thank you. I needed that laugh on a Monday morning like this.

My solution is slower, but 100% effective (5, Funny)

Anonymous Coward | more than 8 years ago | (#13704021)

When my application needs a chunk of memory, it sends a specially crafted HTTPS request to my bank, debits the account, sends a fax to the local computer shop who then sends a tech over to install the DIMMs.

When the application is finished with the memory, it sends a FAX to the local electronics recycling facility who sends out a tech to remove the DIMMs and melt them down into whatever.

Using this method of heap memory allocation (I call it "ACAlloc" for "Anonymous Coward Alloc" has been 100% effective and I have NEVER had a heap overflow exploit in any of my code.

Yes, it's slow, but I am secure.

...And I'm running the most up-to-date 80386 Linux 0.97 kernel. TDz.

Have you ever noticed.. (-1, Offtopic)

ankarbass (882629) | more than 8 years ago | (#13704032)

That the first few replies get the more than their fair share of mod points, even though they generally aren't much more than a hallmark card response?

Don't mod this up, it's OFF TOPIC!!!

Re:Have you ever noticed.. (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#13704097)

No need to worry, you are in no danger of being modded up.

Re:Have you ever noticed.. (1)

ankarbass (882629) | more than 8 years ago | (#13704207)

So it seems, we are birds of a feather.

What's next? (3, Funny)

Groo Wanderer (180806) | more than 8 years ago | (#13704047)

Ok, we start out with 'protection', then we move to 'a heap' of protection, most assuredly to be followed by 'a whole heap' of protection. I can only see this spiral continuing until Bill Gates himself gets up on stage at CES in an Elvis suit promising 'a hunka- hunka- burnin protection'. *SHUDDER* Time to take a cold shower.

              -Charlie

Skinny Elvis (0)

Anonymous Coward | more than 8 years ago | (#13704314)

Gates may pull off a skinny Elvis, but for good ole fat Elvis... "Monkeyboy" Balmer got that all sewn up!

Posted Anonymous to preserve lame hope of a career at Microsoft. *wink*

Sacrfice useability? Nice idea , won't work. (1)

Viol8 (599362) | more than 8 years ago | (#13704059)

"And if we have to sacrifice a little usability on the way there, then so be it."

Nice dream , meanwhile in the real world both users and most coders
(if they dare to admit it) will NOT sacrfice usability or ease of
coding for security measures that (in their minds) are nothing to
do with their application. Unless that is they're forced to either
by company policy or restrictions in the OS. If there are restrictions
in the OS then IT tech leads might start to ask "well, I can do this in
OS A , why won't OS B let me do it? I'll use OS A". Not an ideal situation
but when all that matters is delivery times and saving $$$ then its what
will happen. Security , as ever , will come a poor second.

call bob, bob. (0)

Anonymous Coward | more than 8 years ago | (#13704127)

"well, I can do this in OS A , why won't OS B let me do it? I'll use OS A"
... and call OS A Linux and OS B OpenBSD ...

I hope i dont ever find out how to get memory usage on openbsd, sure as hell ain't "free"...

Totally wrong (2, Insightful)

Anonymous Coward | more than 8 years ago | (#13704153)

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

Re:Sacrfice useability? Nice idea , won't work. (5, Insightful)

Daniel_Staal (609844) | more than 8 years ago | (#13704196)

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.

Re:Sacrfice useability? Nice idea , won't work. (0)

Anonymous Coward | more than 8 years ago | (#13704214)

I understand the sentiment, but ... consider the influence of laws like Sarbanes-Oxley. When CxOs go to jail because of their developers' bad code ... security might become more important.

Re:Sacrfice useability? Nice idea , won't work. (0)

Anonymous Coward | more than 8 years ago | (#13704289)

Um. What Theo means is that incorrectly written programs will fail to work. So, Linux will let you access a free()'d buffer, but OpenBSD will not. Since more programs get tested on Linux than on OpenBSD, the bug is never manifested and no one cares.

So, let's say your favorite software package is one of those programs. You won't be able to use it until someone comes up with a patch that fixes the allocation bugs.

Correctly written programs are unaffected. If you never access what hasn't been allocated, and don't touch what you've told the libc you want freed, you are fine. Can't say that about Linux.

Apologies to the Black-Eyed Peas (2, Funny)

Anonymous Coward | more than 8 years ago | (#13704060)

OpenBSD's "My Heap":

Lookin' at my heap, heap
You can look but you can't touch it.
If you touch it, I'ma start some drama.
You don't want no drama.
[...]
My heap, my heap, my heap, my heap.

Re:Apologies to the Black-Eyed Peas (0, Troll)

mrtroy (640746) | more than 8 years ago | (#13704156)

Immma get get get you drunk Get you love drunk off my heap Immma make make make you scream Make you scream make you scream! [...] My heap, my heap my heap, my heap My lovely lady lumps

Hm... old technique? (4, Interesting)

archeopterix (594938) | more than 8 years ago | (#13704064)

Ok, the article is light on technical details, but it seems that they are using guard pages. Guard pages aren't exactly shiny new. Efence [die.net] has been using them since a long long time.

Hm... gotta reply to myself (4, Informative)

archeopterix (594938) | more than 8 years ago | (#13704105)

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:Hm... old technique? (3, Funny)

Chocolate Teapot (639869) | more than 8 years ago | (#13704129)

Guard pages aren't exactly shiny new

Shhh!! I was waiting until everyone started using them before hitting them with my patent ;)

Re:Hm... old technique? (1)

qwertphobia (825473) | more than 8 years ago | (#13704651)

Ok, the article is light on technical details, but it seems that they are using guard pigs. Guard pigs aren't exactly shiny new. The Battalion [212.58.240.35] has been using them since a long long time.

Microsoft Windows? (2, Funny)

fernique (754349) | more than 8 years ago | (#13704065)

Could this technology be implemented in the Microsoft Windows systems to be more secure than Linux?

Re:Microsoft Windows? (2, Insightful)

Slashcrap (869349) | more than 8 years ago | (#13704247)

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.

My Windows XP has heap protection! (0, Redundant)

callipygian-showsyst (631222) | more than 8 years ago | (#13704081)

Microsoft released this last year. Read the details here [microsoft.com]

As BSD is my other favorite OS (I tend to use XP for desktops and FreeBSD for servers), I'm glad to know that they've finally caught up with Microsoft in this important area.

Re:My Windows XP has heap protection! (4, Informative)

jcupitt65 (68879) | more than 8 years ago | (#13704157)

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:My Windows XP has heap protection! (1)

zootm (850416) | more than 8 years ago | (#13704376)

I think they did add heap protection at the same time, although I hear it's been "broken" (although in practical terms I've no idea).

Re:My Windows XP has heap protection! (1)

Mr. Moose (124255) | more than 8 years ago | (#13704477)

...that says that this page is only code and not data and you shouldn't try to run anything in here

The "only code, not data. DO NOT RUN THIS" flag could be the reason why my Windows box stops working sometimes... Hope the BSD implementation is a bit better.

Re:My Windows XP has heap protection! (1)

Triumph The Insult C (586706) | more than 8 years ago | (#13704390)

this support showed up in openbsd almost 2 years ago

microsoft's support was partial. intel's implementation is partial

openbsd's support is full. amd's implementation is full (and freely documented)

Could this help Gnome? (3, Interesting)

MuMart (537836) | more than 8 years ago | (#13704112)

Sounds like a heap that returns unused pages to the system like this would help the problem described by John Moser in the Gnome Memory Reduction Project here [gnome.org] .

Is it really true that the standard GNU/Linux heap implementation holds onto pages like this when it becomes fragmented? That sounds really primitive to me.

Re:Could this help Gnome? (2, Interesting)

Ulrich Hobelmann (861309) | more than 8 years ago | (#13704616)

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.

Maybe that's primitive, but it ensures that usually small memory requests are fast, and don't have to much space overhead, either.

If the memory de/allocation patterns are really bad, though, you get fragmentation with the mentioned problems. It's a tradeoff. Note that OpenBSD didn't choose its way for reducing heap usage (maybe they use even more memory, due to overheads), but for security reasons.

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. No fragmentation, almost no overhead. 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.

Anyway, I love the new malloc, and kudos to the whole OBSD team!

In related news, GCC 4.1 stack protector (3, Interesting)

joib (70841) | more than 8 years ago | (#13704114)

The upcoming GCC 4.1 release will include a stack protector [gnu.org] . Basically it's a reimplementation of the old propolice patch.

Hopefully mainstream distros that have been wary of propolice will start using this new feature. And perhaps glibc malloc will borrow a few tricks from this new openbsd malloc too.

Re:In related news, GCC 4.1 stack protector (3, Informative)

rehabdoll (221029) | more than 8 years ago | (#13704218)

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

Re:In related news, GCC 4.1 stack protector (1)

stevey (64018) | more than 8 years ago | (#13704505)

And binary packages for Debian's Sarge release on x86 are available here [debian.org] .

Re:In related news, GCC 4.1 stack protector (1)

Triumph The Insult C (586706) | more than 8 years ago | (#13704352)

And perhaps glibc malloc will borrow a few tricks from this new openbsd malloc too.

maybe glibc developers should start small and put strl*() and friends in first ...

Re:In related news, GCC 4.1 stack protector (0)

Anonymous Coward | more than 8 years ago | (#13704578)

Also in related news, OpenBSD has used ProPolice since version 3.4, relased 1 November 2003.

Is there any question that it is ahead of the curve?

Whats so new here? (0)

Anonymous Coward | more than 8 years ago | (#13704121)

"innovation in Unix that talks about OpenBSD's new heap protection mechanism as a major boon for security.", surely you mean "innovation in *BSD " ?

When taking a look at some of the features [sun.com] of my favorite Unix environment [sun.com] you'll notice that among the security features its also possible to shield processes from each other and control the amount of memory they use (near the bottom, the so called "buffer overflow attack"). If you wish to study this in more detail you can check out the documentation on resource control [sun.com] which explains you the issue in more detail. For the impatient; controlling physical memory and such is explained in chapter 10 [sun.com]

Sorry but I can't conclude that this is something new in the world of Unix.

OpenBSD does not matter (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#13704143)

As OpenBSD has a history of not giving back, forking everything and not notifying the upstream authors of any security fixes, this does not matter at all.
When this will be implemented by someone else, fixes might flow in the programs, and something actuall happen...

Re:OpenBSD does not matter (4, Insightful)

Ulrich Hobelmann (861309) | more than 8 years ago | (#13704655)

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.

Already in Microsoft DEP (2, Interesting)

Henry V .009 (518000) | more than 8 years ago | (#13704146)

DEP from Microsoft is only enabled by default on some system binaries. Here is how to enable it for everything: http://www.microsoft.com/technet/security/prodtech /windowsxp/depcnfxp.mspx [microsoft.com]

My CPU doesn't support DEP in hardware, so I imagine the software-based method of doing this will create quite a speed hit. Anybody have any experience with turning on DEP for all programs?

Re:Already in Microsoft DEP (2, Interesting)

Henry V .009 (518000) | more than 8 years ago | (#13704313)

Well, I've turned it on now. No noticeable performance hit, and no mysterious application failures. Just compiled a Visual C++ program and it ran fine. Same for G++ on CYGWIN.

Also, I have not been hacked anytime in the last ~5 minutes, whatever that's worth (but would I know?).

As an aside, I read the paper on the Microsoft DEP flaw a few months ago, and wasn't that impressed. It looks very hard to exploit. And since DEP is a added protection mechanism, the existence of a small, hard-to-expliot flaw isn't that big of a deal. (In simple terms, with DEP on, a hacker would have to exploit and DEP flaw and a normal overrun flaw to hack the system.)

Not the same thing (1, Informative)

Anonymous Coward | more than 8 years ago | (#13704343)

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.

Re:Not the same thing (1)

Henry V .009 (518000) | more than 8 years ago | (#13704591)

Windows hardware-DEP isn't quite the same as its software-DEP (the NX-bit stuff). It also does SafeSEH checks.

Re:Already in Microsoft DEP (0)

Anonymous Coward | more than 8 years ago | (#13704394)

The NX bit (DEP) isn't the same as heap protection.

Wrong solution for solving heap problems. (3, Interesting)

master_p (608214) | more than 8 years ago | (#13704189)

From the kerneltrap.org post:

He explains that for over a decade efforts have been made to find and fix buffer overflows, and more recently bugs have been found in which software is reading before the start of a buffer, or beyond the end of the buffer.

The solution that the kerneltrap.org refers to against buffer overflows is to:

  1. unmap memory as soon as it is freed, so as that to cause a SIGSEV when illegaly accessed.
  2. have some free 'guard' space between allocated blocks.

My opinion is that #1 will slow software down, although it will make it indeed more secure. #2 will make it more difficult to exploit buffer overflows, since the space between two allocated heap blocks will be random (and thus the attacker may not know where to overwrite data).

Unless I haven't understood well, these solutions will not offer any real solution to the buffer overflow problem. For example, stack-based exploits can still be used for attacks. The solution shown does not mention usage of the NX bit (which is i86 specific). It is a purely software solution that can be applied to all BSD-supported architectures.

Since all the problems relating to buffers (overflow and underflow) that have costed billions of dollars to the IT industly is the result of using C, doesn't anyone think that it is time to stop using C? there are C-compatible languages that allow bit manipulation but don't allow buffer overflows; e.g. Cyclone [wikipedia.org] .

Re:Wrong solution for solving heap problems. (1)

cerelib (903469) | more than 8 years ago | (#13704406)

Amen to that last comment. The widespread use of C is probably one of the biggest contributors to unstable and unsecure systems. I am not saying that C does not have its uses, but some things should be reconsidered.

Re:Wrong solution for solving heap problems. (0)

Anonymous Coward | more than 8 years ago | (#13704565)

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.

Re:Wrong solution for solving heap problems. (0)

Anonymous Coward | more than 8 years ago | (#13704575)

Furthermore, you can unmap only allocations greater than a page size. For objects less than page size (which is the majority of the allocations) it still allows dangling accesses after a free.

Even for objects greater than page size, what happens if you run out of the address space? Correct me if I am wrong but, you will have to reuse the previously unmapped pages ... so its a not a fool proof solution.
atlease for dangling references.

Similarly if your buffer overflow is not off by one but by a page size, then a guard page will not help.

Nevertheless its a good step forward.

Unnecessary when using languages that solve this p (2, Insightful)

putko (753330) | more than 8 years ago | (#13704231)

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

Re:Unnecessary when using languages that solve thi (1)

Listen Up (107011) | more than 8 years ago | (#13704499)

ALL buffer and heap overflows in individual programs are the fault of bad programming, not bad programming languages. If a programmer is not competent enough to test their code, and then blame the programming language when there is a problem, should not be coding. It is simply irresponsible.

You forgot to add Java to your list of programming languages which goes out of its way to assist in preventing and avoiding both buffer and heap overflows/errors (i.e. bounds checking and similiar technology).

Finally Locking the Door (4, Insightful)

Doc Ruby (173196) | more than 8 years ago | (#13704241)

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.

Re:Finally Locking the Door (0)

Anonymous Coward | more than 8 years ago | (#13704555)

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

Such a solution would not protect against the following case: the program running is an interpreter, and the attacker changes the program residing in a data segment, e.g. by changing "rm junk" into "rm -r *"

Or are interpreters such as sh, perl and python already mapping script files read-only?

Re:Finally Locking the Door (1)

ep385 (119521) | more than 8 years ago | (#13704604)

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,


You're forgetting about systems that do code generation on the fly such as Lisp systems. In such systems code is data and thus executable code is also just data. It's stored in the heap and must be executable.

Let's not restrict our operating systems to support only the lowest common denominator (the C programming language).

Pax? (0)

Anonymous Coward | more than 8 years ago | (#13704261)

I thought that pax was a tar lookalike that nobody uses.

Also Worth Mentioning (4, Informative)

RAMMS+EIN (578166) | more than 8 years ago | (#13704278)

This presentation [openbsd.org] (by Theo de Raadt) gives a good overview of the security features in OpenBSD (beyond what's already outlined on the OpenBSD security page [openbsd.org] ). 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 [umich.edu] .

Heap protection? (2, Funny)

justforaday (560408) | more than 8 years ago | (#13704280)

I call my heap protection mechanism "bumpers" : p

Linux Had A Spec For This Ages Ago (2, Funny)

Anonymous Coward | more than 8 years ago | (#13704303)

But Linus doesn't like specs so it got dropped !

Kerneltrap link (0)

Anonymous Coward | more than 8 years ago | (#13704307)

In case you wanted to read the Kerneltrap article mentioned but not linked http://kerneltrap.org/node/5584 [kerneltrap.org]

Bring it to the PSP (0)

Anonymous Coward | more than 8 years ago | (#13704333)

Let's hope Sony will bring it to the PSP, so it'll be safe from those dangerous .tif images attacks....

Heap Protection vs. Managed Code (1)

hey (83763) | more than 8 years ago | (#13704355)

I wonder of all these creative heap protection mechanisms (GCC 4.1, NX, etc) will largely remove the need for managed code (ie Java and C#). If you can write in C++ and not worry about double-free()s that pretty neat. Maybe even a "disruptive technology".

Re:Heap Protection vs. Managed Code (1)

Henry V .009 (518000) | more than 8 years ago | (#13704469)

If you are writing in C++, you should
  1. Not be using free in the first place. It's an error to code C++ as if it were C—use new and delete
  2. Not be doing explicit memory management. Use RAII (Resource Acquisition Is Initialization) practices. Not using RAII in C++ is an error. (Beyond resource handling nightmares, you aren't being exception safe without RAII.)

Re:Heap Protection vs. Managed Code (0)

Anonymous Coward | more than 8 years ago | (#13704630)

Well, its not a "error" just bad practice.

Managed code wasn't invented for good and careful programmers, it was invented so
their bosses could be sure that no matter how bad the programmers the application won't have a leak, bound overflow, etc.

Managed code makes that promise and now (or soon) these heap protection thingies will too for conventional languages.

For Real Security (0, Troll)

RAMMS+EIN (578166) | more than 8 years ago | (#13704382)

For real security, don't use C. I've advocated this many times before, and have recently written a new essay about how better programming languages can lead to better software [nyud.net] . Although this essay isn't entirely focused on security, it does demonstrate that some of the most common security bugs simply cannot occur using, in this case, Common Lisp instead of C.

VBLinux (4, Funny)

Frankie70 (803801) | more than 8 years ago | (#13704629)


  For real security, don't use C.


I am rewriting Linux in Visual Basic 6.0.
I am going to call the distro VBLinux.

This is how Electric Fence works. (4, Interesting)

Bruce Perens (3872) | more than 8 years ago | (#13704618)

Electric Fence explicitly allocates dead pages at the end (or configurably, the beginning) of buffers. It can also protect the memory immediately as it is freed. I think it was first published in 1987.

It may be a legitimate invention - it is cited as prior art in an ATT patent. This is also the first known example of a prior Open Source publication causing a patent filer to cite. ATT also removed a claim from the patent that my work invalidated. Just search for "Perens" in the U.S. patent database to find the patent.

We don't run it on production programs because of its overhead. To do this sort of protection exhaustively, it requires minimum two pages of the address space per allocation: one dead page between allocations and one page allocated as actual memory. This is a high overhead of page table entries, translation lookaside buffers, and completely destroys locality-of-reference in your application. Thus, expect slower programs and more disk-rattling as applications page heavily. If you are to allocate and release memory through mmap, you get a high system call overhead too, and probably a TLB flush with every allocation and free.

Yes, it makes it more difficult to inject a virus. Removing page-execute permission does most of that at a much lower cost - it will prevent injection of executable code but not interpreter scripts.

I don't think the BSD allocator will reveal more software bugs unless the programmers have not tested with Electric Fence.

Bruce

/me can't resist (1)

SilverspurG (844751) | more than 8 years ago | (#13704658)

From the article:
" The more hurdles that one has to jump through for good security, the less likely people will go through the trouble. OpenBSD allows even the most inexperienced users to take advantage of these technologies without any effort. "
Can they fix the government, too? It sounds like the same problem.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>