This discussion has been archived.
No new comments can be posted.
OpenBSD Stomping On Buffer Overflows
Related Links Top of the: day, week, month.
"The great question... which I have not been able to answer... is, `What does woman want?'" -- Sigmund Freud
Re:New idea? (Score:3, Informative)
What about (Score:4, Interesting)
Re:What about (Score:1, Insightful)
Re:What about (Score:1)
The parent poster is obviously asking why nobody even uses those libraries or projects with Linux itself--not why don't they use them with OpenBSD. Asking why the OpenBSD project doesn't use a (probably) GPL solution to this problem is like asking why the Pope doesn't buy dungeon porn.
Until then, please shut the jiziont up, because you seem to have jack shat for reading comprehension.
Re:NIH (Score:2)
Includes ProPolice (Score:5, Informative)
Libsafe only protects a few built-in functions; it's not a bad idea, but it's FAR less effective than StackGuard or ProPolice. The Openwall kernel patch is actually a collection of nifty capabilities. The "no executable stack" option is probably what you mean, but it turns out that there's a trivial way around it... so that part is only effective BECAUSE few people use it. Openwall has other stuff that's nice, though.
I think the reason these capabilities aren't in use everywhere (yet) is the conservatism of most distributions. Many distributions worry about any performance loss or compatibility loss. OpenBSD's primary focus is on security, so losing performance or backwards compatibility is not as serious an issue for them. I have hopes that these features will become more mainstream.
Mandrake has provided these for a while (Score:2, Informative)
I used all this stuff in Mandrake 8.1 and there was a noticeable perfo
Already slashdotted (Score:3, Informative)
09:43 Monday 14th April 2003
Robert Lemos, CNET News.com
The OpenBSD project is making changes in its latest operating system release that it believes could eliminate a class of security bugs that has plagued computers for decades
The OpenBSD project hopes new changes to its latest release will eliminate "buffer overflows", a software issue that has been plaguing security experts for more than three decades.
Theo de Raadt, the project leader for the group, believes that the group's latest improvements to the Unix variant, due to be released on 1 May, will make causing a buffer overflow extremely difficult, if not impossible. A buffer overflow is a memory error in software that allows an attacker to run a malicious program.
"I could say that I am killing buffer overflows, but I am in the security community, so I have to put it in quotes," he told attendees at the CanSecWest security show on Thursday.
The memory bugs have resisted extermination for almost 30 years, and de Raadt said that any claims that an open-source group has done so would need to be tested.
Some attendees are already incredulous that the changes will eliminate buffer overflows. "It's just adding another layer" to the security, said Nicolas Fischbach, senior manager for security at Colt Telecom, a European communications provider. "It won't make a huge difference because there are always bugs that are found in software."
An overflow exploit generally works when an attacker sends a program requesting too much information. The data usually includes two components: one that crashes the application and one that's either a program or a memory address that points to a program that the attacker would like to run. When the application crashes due to the first component, the operating system will execute the second.
The OpenBSD team hardened the operating system to this type of attack using three tactics.
The group randomised where in memory the "stack" -- a structure that holds applications and their data -- resides, so that code designed to exploit buffer overflows will have to be tailored to the system's memory layout.
"Buffer overflows take advantage of a certain memory layout," de Raadt said. "It's a tiny waste of memory, with very little overhead, but it makes things a little bit more difficult. We are trying to make the (code) crackers work a little bit more."
In addition, the group restructured how critical addresses are stored on the stack, so that it's harder to get buffer overflows to result in a running program. The team placed a small tag, called a canary, in the memory structure to detect if addresses had been modified, a common method hackers use to get a legitimate program to run malicious code.
Finally, the group found a way to hack the BSD file system and divide main memory into a writable portion and an executable portion. Pieces of programs and data, known as pages, that are stored to memory will be placed into one of the two areas.
"We want to make sure that no page is both executable or writable simultaneously," he said. "The goal is that no hackers should be able to write code and then execute it."
The problem for the OpenBSD group is that while 64-bit processors have such memory protections available, the most-popular 32-bit processors don't. So the group has had to work around the issue and break up a computer's memory into writable and executable areas.
"You can draw a line in the sand -- before that line you can execute, above you can't," de Raadt said.
While the other security features will be available in the 1 May release, the protected memory page structure for 32-bit processors -- such as Intel x86 chips and the PowerPC chips -- won't be ready for another six months, he said.
The research was funded by a $2.3m (about £1.5m) grant from the Defense Advanced Research Projects Agency (DARPA) to the OpenBSD Project, but the latest changes go be
It's a shame that segments work the way they do. (Score:5, Interesting)
It is a shame that Intel made segments work the way they do, because a minor tweak and segments would have been the perfect way to prevent buffer overflows in hardware.
Consider: what if, instead of segment descriptors having to live in the GDT and LDT, they could be loaded into a register from a normal memory limit? True, they would then have been useless for OS level protection, but I assert that is what the page map is for (yes, the page mapper didn't exist prior to the 386, and enhanced segments showed up in the 286).
In some of the DSPs that I work with, you have registers to specify a region of memory. When you access off these registers, memory bounds are enforced by the chip (this allows for circular regions of memory, bit reversed addressing, and other weird things you need when doing DSP work).
What if you could have done something like this:
buffer:
ds 1024 ; a buffer of stuff
buffer_descr:
dd buffer ; where buffer starts
dd 1024 ; sizeof(buffer)
LDPROT ES,buffer_descr ; set limits checking
LD ES:(ESI),EAX ; store to buffer with checking.
Thus, any access out of bounds would throw a SIGSEGV.
Then, the code could have provided protection against overflows without explicit checking on every array access. True, this would not protect you if all you were given was the buffer address, but in the presense of this sort of hardware, GCC could have been modified to make a char (*a)[] (pointer to array of char) be three elements - base, sizeof(), index.
No, it;'s a shame how kernel developers use them (Score:2)
No, it is not the kernel devs fault. (Score:3, Interesting)
If auto storage is removed from the call/return stack, I can overwrite another variable somewhere else, perhaps tricking your program into thinking it is debug mode. It gets harder, but not impossible.
What I was discussing was fine-grained memory bounds checking - which you simply cannot do when all you have is 8192 LDT a
Overlapped code/data a mistake. BOUND instr. avail (Score:3, Interesting)
Re:Overlapped code/data a mistake. BOUND instr. av (Score:3, Interesting)
Even if the program space and the data space were completely seperate I can trivially smash the stack and get a shell - again, all I have to do is overwrite the current function return address with the address of execv, and the preceeding addresses with a bogus return address and pointer to the strings "/bin/sh", 0, and 0. No code segment overlap needed.
Secondly, the BOUND instructi
Re:Overlapped code/data a mistake. BOUND instr. av (Score:3, Interesting)
No, it is not needed globally. It can be selectively used just like the code you suggested previously. Secondly, your solution bloats the code as well, your LDPROT instruction and segment override prefix consumes cache space as well.
Your assertion that seperate code and data spaces in the kernel is like locking the doors on a convertable - it may make you fe
Re:Overlapped code/data a mistake. BOUND instr. av (Score:3, Interesting)
As for the code/data space issue - the issue at hand is stack-smashing and array bounds violations - neithe
Re:Overlapped code/data a mistake. BOUND instr. av (Score:3)
You had a segment override prefix on every data access. That is not free, space of performance.
Been there, done that. I wrote a custom kernel for a telecommunication product. We used a commercial compiler and linker that targets embedded environments and
Re:Overlapped code/data a mistake. BOUND instr. av (Score:3)
And protecting the code from modification is much better done by protecting the pages themselves in the page table than by using segementation tricks.
Re:No, it;'s a shame how kernel developers use the (Score:2)
Nonexecutable read-write pages would have helped a lot in some cases. AFAIK that is not supported by the CPU. Only through nasty hacks doing stuff with undefined behaviour has it been possible to implement it.
The developers choose to make the code and data segments overlap, that is the error.
No that is certainly not an error. It is the way to go if you want to use a paged memory model on IA32. You cannot blame the kernel developers for some security feature
Re:No, it;'s a shame how kernel developers use the (Score:2)
I don't see where having code and data segments being aliases for one another has anything to do with paging. IA32 is always segmented, a flat memory model means one code segment and one data segment, and basing code and data at the same logical address is me
Re:No, it;'s a shame how kernel developers use the (Score:2)
It simply means that you can ignore the little usable segmentation and use the pure paging that is below the segmentation.
At the program level, OS or app, we have segment+offset.
That is actually not the case in Linux IA32. A pointer is merely an integer.
The special case of the flat model with code and data based at logical address zero is merely a historical convention of UNIX, it may be
Re:No, it;'s a shame how kernel developers use the (Score:2)
That is actually not the case in Linux IA32. A pointer is merely an integer
You are mistaken. Linux, Win32, or any other OS has no say in the matter, there is always segmentation in IA32. You are confusing a special case of the flat memory model where all segment are based at zero with the lack of segmentation. From the CPUs perspective a pointer is always an offset into a segment. A segment base address defined in the descriptor table is always adde
Re:No, it;'s a shame how kernel developers use the (Score:2)
The CPU might see it as segmentation, but at the program and OS levels there is no segmentation. In fact most Linux programs never touch a segment register, from the programs point of view the segment registers could as well be nonexistent. And those parts of Linux actually dealing with segment registers are few.
I merely prefer different bases so that code and data do not overlap in the logica
Re:No, it;'s a shame how kernel developers use the (Score:2)
Again, your use of the word "segmentation" is different than the use of this word in the original discussion. I.e. you are off on a tangent all alone. One last time, segmentation is always on in
Great ideas! But what about the "file system"? (Score:3, Interesting)
But my real question is about that ZDNet article. It said that the segmentation measures came from "hacking the BSD file system". It sounds to me like the reporter got confused. Can anyone familiar with the code comment on this?
Re:Great ideas! But what about the "file system"? (Score:1)
Now it
Re:quick suggestion ... (Score:2, Informative)
Flexibility (Score:1, Offtopic)
I really appreciate the effort going into OpenBSD making it more secure and robust, but I hope the option of keeping it a simple BSD without the innovative security features, remains. Part of the reason Ive used BSD in the past is its simplicity and predictability across the versions. OpenBSD, opposed to NetBSD and FreeBSD is the 'simplest' BSD outside of the seccurity changes and I hope users have the option of not using the page protection, encrypted ram and filesystems, chrooted services and other stuf
Is the randomization per machine, per build, etc? (Score:3, Interesting)
but this is still vague. It could be:
- Per kernel. (All processes on this box have the same stack layout)
- Per process. (All processes have a different stack layout, though threads and forked versions may have the same.)
- Per binary. (Each program's stack layout is determined at compile time and will not change on invocation.)
- Completely random (Each program is different every time, or better yet each function call is different each time.)
This would have a very import impact on how well a hacker could brute force your processes. If a given process always has the same stack layout then you can eventually brute force it, just like we currently can brute force offsets. The bar is higher of course - only one variable is being manipulated - and a hacker will probably go to easier machines before too long. But a truly randomized per process invocation or better yet per function call invocation would be such a moving target that it should be extreemly unlikely to succeed. I'm really excited.Re:Is the randomization per machine, per build, et (Score:1)
What kind of... (Score:3, Funny)
------------
This quote clearly demonstrates that free as in beer is not free at all. Even the most notorius free software developers actually pay money for their beer.
Gates said hardware should be free. Stallman said software should be free. I think beer should be free.
Re:What kind of... (Score:2)
Re:What kind of... (Score:2)
Then perhaps you should join the Free Beer Foundation [theravensnest.org].
Re:What kind of... (Score:2)
I am firmly of the opinion that assembly requires 190 proof pure grain. Especially on the fucking IBM 360/370. Nothing else dulls the pain.
Re:What kind of... (Score:2)
buffer over flow exploits not truly eliminated (Score:3, Interesting)
"An overflow exploit generally works when an attacker sends a program requesting too much information. The data usually includes two components: one that crashes the application and one that's either a program or a memory address that points to a program that the attacker would like to run. When the application crashes due to the first component, the operating system will execute the second.
It is important to point out that this looks to be yet another in the attempts at making buffer over flow exploits difficult yet not quite impossible. Once you put return addresses on the stack (the same stack with an over flow) an exploit can jump to any place it likes in text even without an executable stack.
The details about the tag around import addresses and the random stack offsets could make exploits _very_ difficult. If the base of the stack is random from one invocation of the program to the next that does not give much more once you cannot execute on the stack so it is probably more than that. Also if the tag around important addresses (say the address of the buffer to system(3C)) incorpates randomness from one invocation of the program to the next then it would be hard to over flow a buffer and exploit it.
In any case even if you had a sytem where a buffer over flow could not be exploited to run arbitrary code but almost any random junk will still crash the broken prorgam, that does not do much to prevent DoS now does it.
Re:buffer over flow exploits not truly eliminated (Score:3, Informative)
The reason you cannot smash the stack is that when you overflow it