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

https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/

by vzaliva • 7 months ago

164 42 7 months ago

mgerdts• 7 months ago

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;

flatline• 7 months ago

According to the chatbot, the first word of `fin` is the file descriptor, the second its state. "Reset stdin’s flags to a clean state".

oguz-ismail2• 7 months ago

Predecessor of

    extern FILE *stdin;

formerly_proven• 7 months ago

I’m guessing v4 C didn’t have structs yet (v6 C does, but struct members are actually in the global namespace and are basically just sugar for offset and a type cast; member access even worked on literals. That’s why structs from early unix APIs have prefixed member names, like st_mode.

Boltgolt• 7 months ago

)

topspin• 7 months ago

I’m guessing v4 C didn’t have structs yet

There may have been a early C without structs (B had none,) but according to Ken Thompson, the addition of structs to C was an important change, and a reason why his third attempt rewrite UNIX from assembly to a portable language finally succeeded. Certainly by the time the recently recovered v4 tape was made, C had structs:

    ~/unix_v4$ cat usr/sys/proc.h
    struct proc {
            char    p_stat;
            char    p_flag;
            char    p_pri;
            char    p_sig;
            char    p_null;
            char    p_time;
            int     p_ttyp;
            int     p_pid;
            int     p_ppid;
            int     p_addr;
            int     p_size;
            int     p_wchan;
            int     *p_textp;
    } proc[NPROC];

    /* stat codes */
    #define SSLEEP  1
    #define SWAIT   2
    #define SRUN    3
    #define SIDL    4
    #define SZOMB   5

    /* flag codes */
    #define SLOAD   01
    #define SSYS    02
    #define SLOCK   04
    #define SSWAP   010

b-kuiper3• 7 months ago

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?

b-kuiper3• 7 months ago

EDIT: removed due to low effort and mark-up issues. thank you all for your feedback.

b-kuiper3• 7 months ago

perhaps the downvoters can tell me why they are downvoting? i'm curious to hear whether if this would work on unix v4 or whether there are special things to consider. I thought i would ask claude for a basic example so people could perhaps provide feedback. i guess people consider it low effort reply? anyway, thanks for your input.

MajesticHobo2• 6 months ago

Yeah, somebody came up with one here: https://news.ycombinator.com/item?id=46469897

ChrisArchitect• 7 months ago

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

nineteen9993• 7 months ago

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

retrac• 6 months ago

x86_64 v4 UNIX port

What compiler are you using?

nineteen9993• 6 months ago

gcc. Im also working on a port of the original compiler, but that's a much lower priority for me.

nullpoint420• 6 months ago

That sounds really fun!

SoftTalker• 7 months ago

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.

fooker2• 7 months ago

The amount of code was relatively low.

Not the million line codebases we have today. 50-100 lines was the usual program or script.

avadodin3• 6 months ago

iirc they were initially using actual ttys(as in typewriters) and the input delay was hell which is the reason so many UNIX commands are two letters.

So likely they would work on the printout:

   1,$n

And then input the corrections into ed(1).

irusensei• 6 months ago

I had to use it when I installed 9front on a computer that has no graphics card just a serial port (APU2C2). I had only a serial device at 9600bps and the other text editors (sam, acme) didn't worked. I wanted to turn it into a CPU server so I can use drawterm to access it remotely and that requires editing a few files.

b00ty4breakfast• 6 months ago

ed makes a lot more sense if you remember they were printing everything to paper rather than using a glass tty when it was first developed

butterisgood• 6 months ago

I think ed is still a great editor for specific tasks. As a plan 9/9front user, when you get yourself into trouble, it's sometimes the only editor you've got left (like when graphics doesn't initialize, which I've not seen on 9front — ever?)

It's really not bad, and you can use it for scripting like sed, but it's clunkier.

kazinator• 7 months ago

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

# ... sound of crickets ...

Wanna see me do it again?

nineteen9993• 6 months ago

Remotely? ... this version of UNIX doesn't have any networking.

w-m• 7 months ago

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.

loeg• 6 months ago

will you overwrite pwbuf when writing past password?

Right.

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?

Almost. You need to type crypt(password) in the part that overflows to pwbuf.

asveikau3• 6 months ago

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;

You don't actually need i here. i is the same as (q - password). It would be idiomatic C to simply rewrite the loop condition as: while (q < password+sizeof(password) && (*q = getchar()) != '\n'). To preserve your "goto error;" part, maybe you could do the overflow check when null terminating outside the loop.

shakna• 6 months ago

Isn't sizeof only standardised in C89? Wouldn't shock me if this form needs to be an rvalue.

The author did try pointer arithmetic:

I initially attempted a fix using pointer arithmetic, but the 1973 C compiler didn’t like it, while it didn’t refuse the syntax, the code had no effect.

asveikau3• 6 months ago

This surprised me too. The snippet I was quoting from was already using sizeof, though.

I missed the blurb about pointer arithmetic. Would be interesting to go into detail about what "had no effect" means.

VonTum• 6 months ago

The article specifically mentions this optimization as not working with the compiler at that time, hence the need for the separate index variable.

We will edit su.c to prevent the overflow by maintaining a counter, i, and verifying it against the buffer size during the read loop. I initially attempted a fix using pointer arithmetic, but the 1973 C compiler didn’t like it, while it didn’t refuse the syntax, the code had no effect. I settled on a simpler index-based check instead.

asveikau3• 6 months ago

Your sibling comment mentions it.

There's no details.. why didn't it work? Maybe the author didn't write it correctly? No word on what the assembly output for it was...

WalterBright2• 6 months ago

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

WalterBright2• 6 months ago

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.

emilfihlman• 6 months ago

The source has

ttybuf[2] =& ~010;

Which is another bug.

messe• 6 months ago

What's the bug? If you're referring to the =& syntax, then that's just how &= used to be written in older versions of C.

serpent• 6 months ago

Are you sure any buffer overflows were actually fixed in 1973?

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

Related Stories