Fixing a Buffer Overflow in Unix v4 Like It's 1973

A bit of a code review (some details from the patch removed for clarity):

   +       register int i;
           q = password;
   -       while((*q = getchar()) != '\n')
   +       i = 0;
   +       while((*q = getchar()) != '\n') {
   +               if (++i >= sizeof(password))
   +                       goto error;

Back in the 80s, when I was writing a C compiler, C compilers typically had a maximum size for string literals. The behavior was to detect overflow, issue an error message, and fail compilation.

I took a different tack. The buffer was allocated with malloc. When a string was larger, it was realloced to a larger size. This worked until memory was exhausted, and then the program quit.

It was actually less code to implement than having a fixed size buffer.

Ditto for the other compilation limits, such as length of a line. The only limit was running out of memory.

What is up with fin? Is it really just writing an int 0 in the memory right after some variable present in libc or similar?

        extern fin;

        if(getpw(0, pwbuf))
                goto badpw;
        (&fin)[1] = 0;

I had to use ed once in a very limited recovery situation. I don't remember the details but even vi was not an option. It's not terrible if you just need to change a few lines. Using it on a teletype to write code all day would get tedious quickly. Full-screen editors had to have been an amazing productivity boost.

Already patched this on my x86_64 v4 UNIX port. Hehe.

The password and pwbuf arrays are declared one right after the other. Will they appear consecutive in memory, i.e. will you overwrite pwbuf when writing past password?

If so, could you type the same password that’s exactly 100 bytes twice and then hit enter to gain root? With only clobbering one additional byte, of ttybuf?

Edit: no, silly, password is overwritten with its hash before the comparison.

so, is there already somebody that wrote the exploit for it? are there any special things to consider exploiting such architecture back in the day or do the same basic principles apply?

Having a buffer with a fixed size is always a red flag for further checking.

Related:

An initial analysis of the discovered Unix V4 tape

https://news.ycombinator.com/item?id=46367744

Unix v4 (1973) – Live Terminal

https://news.ycombinator.com/item?id=46468283

The source has

ttybuf[2] =& ~010;

Which is another bug.

Remotely exploiting a buffer overflow in Unix like it's 1973.

# ... sound of crickets ...

Wanna see me do it again?