Slashdot Mirror
33-Year-Old Unix Bug Fixed In OpenBSD
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."
Wouldn't want to let anyone take over your system with yacc. Seriously.
Unix beards were Unix stubble
Dupe de dupe dupe dupe!
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?
The reason girls and Windows users don't understand UNIX is because all the documentation is in Man files.
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.
But this code just seems wrong. What is C code doing referencing the stack pointer directly?
http://it.slashdot.org/article.pl?sid=08/05/11/1339228
Hail Eris, full of mischief...
E pluribus sanguinem
Damn. Ignore that, it's a different ancient Unix bug.
Hail Eris, full of mischief...
E pluribus sanguinem
I bet you they're not talking about the system stack pointer. Remember, yacc is a parser generator; parsing algorithms always use some sort of stack data structure. So, the "stack pointer" in question is just a plain old pointer, pointing into a stack that yacc's generated code uses.
Are you adequate?
Does anyone know if there's a way to make bsd.slashdot.org show up as a section on the main lefthand menu?
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?
Dewey, what part of this looks like authorities should be involved?
And next week some clevel clogs fixes where humanity fucked up with Free Will.
Forgive me if this is obvious but if the bug goes that far back will it not affect all other unixes that are based on this same source code - not just OpenBSD?
http://projectleader.wordpress.com
Meh, real men use Bison...
It is now official. Netcraft confirms: *BSD is dying
One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be the Amazing Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.
FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.
Let's keep to the facts and look at the numbers.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.
Fact: *BSD is dying
OpenBSD was using GCC as their default compiler until just a few years ago. They, however, wanted a BSD/ISC licensed C-compiler, so they got an ancient open-source one and started hacking it to get it up to modern C standards. They also wanted a secure compiler, since OpenBSD is all about security, and GCC is way too complex to figure out all the possible security issues that might pop up.
It is not broken. The fact that it complains "too many arguments" is evidence that it is not broken, since the program (ls) is doing bounds checks on the input. If it was broken, you wouldn't get the message; there would be a buffer overflow because the programmer didn't do constraints checking.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I'll catch myself before someone else does. Everything I said above is true, except that ls isn't complaining. The OS, specifically exec() and friends, is complaining because the command line length when the shell expands the wildcard exceeds ARG_MAX. Increase ARG_MAX if you want to allow more files, or use a variation of find with the -exec option or xargs, etc.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Note to self: Don't worry about having that extra 2k of core memory as the buffer overrun does not work anymore. Sweet.
"Computers are a lot like Air Conditioners" "They both work great until you start opening Windows"
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.
This sig is part of your complete breakfast.
You're correct that's it's not the right way to do it. The problem is *why* it's not the right way to do it. It's not the right way to do it because the arg mechanism chokes on it due to arbitrary limits, and/or because your favorite shell chokes on it first, forcing you to use workarounds. Choking on arbitrary limits is a bad behaviour, leading to buggy results and occasional security holes. That's separate from the question of whether it's more efficient to feed a list of names to xargs or use ugly syntax with find.
Now, if you were running v7 on a PDP-11, there wasn't really enough memory around to do everything without arbitrary limits, so documenting them and raising error conditions when they get exceeded is excusable, and if you were running on a VAX 11/780 which had per-process memory limits around 6MB for some early operating systems, or small-model Xenix or Venix on a 286, it's similarly excusable to have some well-documented arbitrary limits. But certainly this stuff should have been fixed by around 1990.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Will any proprietary business be ready to accept that their product had a bug for the past 3 decades which was identified only now? Does this mean the community is not very active? But somehow this do not seem to bring negative impact in the minds of people as most of the open source consumers know that this means that even the old code is continuously tuned and open source guys have realistic sensible expectations.
Any word on when they're going to fix the even older "Too many arguments" bug?
Use linux instead.
CHANGELOG
git commit
Soft limits can actually mitigate bugs. If we limit processes by default to 1,024 file descriptors, and one of them hits the limit, that process probably has a bug, and would have brought the system to its knees had it continued to allocate file descriptors. Programs designed to use more descriptors could to increase the limit.
"It's dead, Jim."
I just finished reading the "The A-Z of Programming Languages" series on Computerworld (found out about it in here), and now the next article in the series just came up and it's a chat with the creator of Yacc.
Coincidence?
And for those that want to read the interview, it can be found here.
/ The Arrow
"How lovely you are. So lovely in my straightjacket..." - Nny
Only two or three remote holes in the default install not from 33 years ago, in more than 10 years but not less than 33 years!
Kriston
While xargs is a great little workaround/workhorse, it is needed in far too many cases. Why on earth would it be so hard to increase the limits every once in a while? After all, the limit in question was probably perfectly acceptable back in the day when 20mb was a lot of space and 500 files was more files than you could imagine ever creating.
Stop the brainwash