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

Comments

Re:Great!

[Dadoo]

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

Re:Other Unixes

[X0563511]

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.

Re:You do realize..

[QuantumG]

yacc is not a compiler,

Excuse me?

Yet Another Compiler Compiler most definitely is a compiler.

Re:Great!

[Just Some Guy]

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:

$ find -name 'a*' -print0 | xargs -0 ls -l

which only spawns a new process every few thousand entries or so.

Re:Great!

[Jeffrey Baker]

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

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

Re:You do realize..

[wb8wsf]

OpenBSD still uses GCC, version 3.3.5 on i386. I can't say which version is used on the other platforms.

You are talking of PCC, which is being worked on by some of the OpenBSD developers, but I think its a parallel project, see http://pcc.ludd.ltu.se/
for more information.

Jem Matzen talked of this too, see http://www.thejemreport.com/mambo/content/view/369/

Re:Yeah, it's probably you.

[tomhudson]

From the link you cited:

By 1971, our miniature computer center was beginning to have users. We all wanted to create interesting software more easily. Using assembler was dreary enough that B, despite its performance problems, had been supplemented by a small library of useful service routines and was being used for more and more new programs. Among the more notable results of this period was Steve Johnson's first version of the yacc parser-generator [Johnson 79a].

The code for yacc was certainly not originally written in c - c didn't exist at that time.

In 1978 Brian Kernighan and I published The C Programming Language [Kernighan 78]. Although it did not describe some additions that soon became common, this book served as the language reference until a formal standard was adopted more than ten years later.

The "archaic behaviour" was never part of that standard - it was a mistake in early implementations while they were still "working out the details" of the language, well before K & R, as Ritchie says:

After the TMG version of B was working, Thompson rewrote B in itself (a bootstrapping step). During development, he continually struggled against memory limitations: each language addition inflated the compiler so it could barely fit, but each rewrite taking advantage of the feature reduced its size. For example, B introduced generalized assignment operators, using x=+y to add y to x. The notation came from Algol 68 [Wijngaarden 75] via McIlroy, who had incorporated it into his version of TMG. (In B and early C, the operator was spelled =+ instead of += ; this mistake, repaired in 1976, was induced by a seductively easy way of handling the first form in B's lexical analyzer.)

It wasn't an archaism in c - it was an archaism from b that was removed during the development of what became c. Small difference, and for all practical purposes, it gives the same result - previously-working code that wasn't reviewed as the language evolved towards a standard ended up with "implementation-dependent behaviour" - bugs ... The worst part is that the buggy code is syntactically correct, so no compiler warnings. Of course, if your conforming compiler doesn't give a warning, you assume that the code written with the experimental versions is still valid.