Slashdot Log In
33-Year-Old Unix Bug Fixed In OpenBSD
Posted by
kdawson
on Tuesday July 08, @08:10PM
from the yet-another-stack-overflow dept.
from the yet-another-stack-overflow dept.
Ste sends along the cheery little story of Otto Moerbeek, one of the OpenBSD developers, who recently found and fixed a 33-year-old buffer overflow bug in Yacc. "But if the stack is at maximum size, this will overflow if an entry on the stack is larger than the 16 bytes leeway my malloc allows. In the case of of C++ it is 24 bytes, so a SEGV occurred. Funny thing is that I traced this back to Sixth Edition UNIX, released in 1975."
Related Stories
[+]
IT: The 25-Year-Old BSD Bug 213 comments
sproketboy writes with news that a developer named Marc Balmer has recently fixed a bug in a bit of BSD code which is roughly 25 years old. In addition to the OSnews summary, you can read Balmer's comments and a technical description of the bug.
"This code will not work as expected when seeking to the second entry of a block where the first has been deleted: seekdir() calls readdir() which happily skips the first entry (it has inode set to zero), and advance to the second entry. When the user now calls readdir() to read the directory entry to which he just seekdir()ed, he does not get the second entry but the third. Much to my surprise I not only found this problem in all other BSDs or BSD derived systems like Mac OS X, but also in very old BSD versions. I first checked 4.4BSD Lite 2, and Otto confirmed it is also in 4.2BSD. The bug has been around for roughly 25 years or more."
Firehose:33 year old Unix bug fixed in OpenBSD by Anonymous Coward
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Time to patch (Score:5, Funny)
Reply to This
Re:Time to patch (Score:5, Funny)
But ./ is already taken over with yak. Seriously.
Reply to This
Parent
Re:Time to patch (Score:5, Funny)
Speaking of old bugs the guy who sits next to me at work hooked a 15yo mainfame bug a few months back. His stock comment whenever someone mentions it is: "Three more years and that one would have been old enough to vote!"
Reply to This
Parent
From back when (Score:5, Funny)
Unix beards were Unix stubble
Reply to This
bad omen (Score:5, Funny)
a 33 year old bug, plus a 25 year old bug (http://it.slashdot.org/article.pl?sid=08/05/11/1339228)....
if we keep going backwards, will the world implode? or will daemons start spewing out of cracks in time and space?
Reply to This
Re:bad omen (Score:5, Funny)
Reply to This
Parent
Re:bad omen (Score:5, Funny)
It's just as possible people are wasting time fixing unimportant issues and ignoring more important ones.
We're talking programmers here, not politicians...
Reply to This
Parent
Re:bad omen (Score:5, Funny)
Sure. Break malloc even worse to allow for backwards compatibility.
See "Windows 95".
Reply to This
Parent
Re:bad omen (Score:5, Funny)
a 33 year old bug, plus a 25 year old bug (http://it.slashdot.org/article.pl?sid=08/05/11/1339228)....
if we keep going backwards, will the world implode?
Well since time began only 38.5 years ago we should find out the answer very soon!
Reply to This
Parent
Re:bad omen (Score:5, Interesting)
Reply to This
Parent
Re:bad omen (Score:5, Funny)
The next bug will be in Boolean logic. After that, OpenBSD devs will start fixing structural engineering errors the Tower of Pisa.
Reply to This
Parent
Great! (Score:5, Interesting)
Any word on when they're going to fix the even older "Too many arguments" bug?
Sorry, but any modern system where a command like "ls a*" may or may not work, based exclusively on the number of files in the directory, is broken.
Reply to This
Re:Great! (Score:5, Funny)
Reply to This
Parent
Re:Great! (Score:5, Funny)
Burn the contents of the tar archive onto a CD. Mount the CD over the original directory structure. Use find(1)'s -fstype option to locate all the files that aren't on the CD, copy them to an empty disk image, then eject the CD. Remount the disk image over the original directory, delete all the files in the directory, then unmount the disk image. The files identical in name to those that were on the disk image (which are those that weren't on the CD) won't be deleted thanks to the peculiarities of mount(2).
You're welcome.
Reply to This
Parent
Re:Great! (Score:5, Informative)
While I'm sure you're trolling, I feel I should point out that, 1) I agree with you, and 2) this has apparently been fixed, on Linux:
http://agnimidhun.blogspot.com/2007/08/vi-editor-causes-brain-damage-ha-ha-ha.html [blogspot.com]
Reply to This
Parent
Re:Great! (Score:5, Interesting)
If "ls a*" isn't working, it's because the shell is expanding a* into a command line >100kB in size. That's not the right way to do it.
Try "find -name 'a*'", or if you want ls -l style output, "find -name 'a*' -exec ls -l {} \;"
Reply to This
Parent
Re:Great! (Score:5, Informative)
if you want ls -l style output, "find -name 'a*' -exec ls -l {} \;"
Yeah, because nothing endears you with the greybeards like racing through the process table as fast as possible. Use something more sane like:
which only spawns a new process every few thousand entries or so.
Reply to This
Parent
Re:Great! (Score:5, Informative)
It's both. The kernel is responsible for setting up the execution environment, and in the past it used a fixed 32 pages for the arguments. 32 pages on an ordinary PC is 128KiB, which is the old limit. The new limit is that any one argument can be up to 32 pages, and all the arguments taken together can be 0x7FFFFFFF bytes, which is ~2GiB.
Here's the diff: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=b6a2fea39318e43fee84fa7b0b90d68bed92d2ba;hp=bdf4c48af20a3b0f01671799ace345e3d49576da [kernel.org]
After that, it was up to libc people to fix the globbing routines. Ulrich Drepper, taking some time off from his full-time job of being an asshole on mailing lists, managed to work this into glibc 2.8:
http://sourceware.org/ml/libc-alpha/2008-04/msg00050.html [sourceware.org]
Reply to This
Parent
Was it really a bug back then? (Score:5, Interesting)
Was this a bug when it was originally written, or is it only because of recent developments that it could become exploitable? For instance, the summary mentions stack size. I could imagine that a system written in 1975 would be physically incapable of the process limits we use today, so maybe the program wasn't written to check for them.
Does your software ensure that it doesn't use more than an exabyte of memory? If it doesn't, would you really call it a bug?
Reply to This
Re:Was it really a bug back then? (Score:5, Insightful)
If you overflow a buffer then it's a bug, whether it is exploitable or not.
Reply to This
Parent
Re:Was it really a bug back then? (Score:5, Funny)
If you overflow a buffer then it's a bug, whether it is exploitable or not.
If you can overflow an exabyte-sized memory buffer, you deserve a fucking medal.
Reply to This
Parent
Re:Was it really a bug back then? (Score:5, Funny)
You'll get it when the buffer overflows. If you're running it on a system that processes a billion of those loops per second, that should be in a bit over 31 years. Scale accordingly for your processor and memory speed.
Reply to This
Parent
Hilarious! (Score:5, Funny)
Funny thing is that I traced this back to Sixth Edition UNIX, released in 1975
My sides are completely split! Invite this guy to more parties.
Reply to This
Re:Other Unixes (Score:5, Informative)
Yes. But OpenBSD fixed it, so they get credit for the fix. It's up to the maintainers of the other unix(ish) versions to implement the fix.
Reply to This
Parent
Re:You do realize.. (Score:5, Informative)
yacc is not a compiler,
Excuse me?
Yet Another Compiler Compiler most definitely is a compiler.
Reply to This
Parent