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.
Let's hope it's not as broken as Microsoft's attempt in SP2.
But why did it take so long to implement?
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.
Business Voyeur
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.
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
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.
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 has been using them since a long long time.
Could this technology be implemented in the Microsoft Windows systems to be more secure than Linux?
igor
"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
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.
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.
The upcoming GCC 4.1 release will include a stack protector. 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.
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
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?
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
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).
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.
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:
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.
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_
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
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.
I call my heap protection mechanism "bumpers" : p
I'll turn into a supernova and burn up everything. Well I'll turn into a black little hole and you'll turn into string.
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 ^_^)
Perfecting Discordia
www.stevenvansickle.com
But Linus doesn't like specs so it got dropped !
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.
Please correct me if I got my facts wrong.
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. :-)
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
Bruce Perens.
For real security, don't use C.
I am rewriting Linux in Visual Basic 6.0.
I am going to call the distro VBLinux.
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'd be interested to know what the performance impact of this is - exactly what counts as "too much of a slowdown".
Application heap allocation has "traditionally" been fairly inexpensive unless the heap has to be grown (update a couple of free block pointers/sizes) and the cost of growing the heap (which requires extending the virtual address space and therefore fiddling with page tables which would on a typical CPU require a mode change) is mitigated by allocating more virtual address space than is immediately needed.
If free space is always unmapped then each block allocation will require an alteration to the page tables, as will each unallocation. Not to mention that could cause the page-translation hardware to operate sub-optimally since the range of addresses comprising the working set will constantly change.
If most allocations are significantly less than a page size, then the performance impact may be minimal since whole pages will rarely become free, but if allocations typically exceed a page size, that would no longer be true. If the result is that some applications simply implement their own heap management to avoid the overhead, then you've simply increased the number of places that bugs can occur.
From the examples in the essay, you could easily make the case that for real security use good code.
Who ordered that?
Just curious,
Do you also advocate four times the memory usage and double the speed? Do you blame the language or the speaker when they can't formulate a proper sentence construct? How about we just teach the programmers better instead of bitching about the tool they use.
If half the C coders out there knew the differences between stack, heap, and namespaces, we would not even be debating this issue. Don't blame the coders, blame the universities.
Enjoy,
It's just the normal noises in here.
Its just Windows 2000 with a 1 added for each bugfix
The system had the verbosity of HTML combined with all the readability of compiled assembly viewed as bitmap images
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.
You're totally right, dude.
Let me know when you release your Haskell version of Sendmail, and I'll switch over immediately.
2005 self would counter with, "Yeah, the pointers will be bigger than they used to be, but you progam in high-level languages now, so you don't ever worry about that. It's the compiler's problem."
1987 Sloppy would say, "But I'm going go write a compiler!"
2005 Sloppy would say, "You fuckwit, you never got anywhere on that project. You barely even started it. Too much time fucking around with graphics and genetics."
1987 Sloppy would say, "But, but, it's not fair! Segmentation is an x86 thing. Everyone knows that in the future, we'll all be using 68k. 68k doesn't do segmentation."
2005 Sloppy would sigh.
1987 Sloppy would say, "Oh come on. There's no way people are still using x86 in the 21st century, or even in the 1990s. No fucking way."
2005 Sloppy would just shrug. There's nothing to do in a situation like this. There's nothing you can say. They'll never believe you.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
It always surprises me when something like this gets modded up on /.
This I believe is one of the key differences between programmers and computer scientists. I would simply love to see something with the complexity of sshd or sendmail written in Haskell, Lisp, Scheme, or whatever the current interpreted language is en vogue. Seriously, show me the code! Benchmark some enterprise-level (as in, used in businesses, not the buzzword) non-trivial app (like the aforementioned) written in C/C++ compared to it's interpreted counterpart. I would be incredibly surprised if Apache, Mozilla, Word, whatever would run with anywhere near the speed or responsiveness.
Your opinion (which you are of course entitled to) ignores things like Operating Systems, embedded devices, and even the runtimes/interpreters/virtual machines themselves. And then who is going to maintain this code? Haskell and friends don't have anywhere near the mindshare that C/C++/Java have. You're right.. in theory, using C is terrible, but in reality the other options are worse for different reasons.
Bill
You don't "rearrange" the MMU, you just check/clear the dirty bit in the page table. This bit is set by the hardware regardless so setting it is zero overhead. Clearing these bits is still only 0.006% the time of scanning all of memory. So unless you write to 32k unique pages per GC you get a huge benefit from this.
You could probably also use the MMU to reduce pauses in the gc... you determine what objects are unreachable in the background and using the dirty bit you can tell which pages may have references into the set, so instead of starting over from scratch again you just weed out the now-reachable objects from the set, which seems like it should be a much more tractable problem.
If I wasn't working I would do this. Check out jnode or jxos for example.
Check out libumem -- much more powerful than this and has been around in Solaris for years (granted, the manpage should be better to reveal the powerful features -- but a quick look at the source at opensolaris.org reveals how to use the most advanced features).