3 ms·

Reading the source unearths interesting things: https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/ https://sigma-star.at/blog/2025/12/unix-v4-buffer-ov

Reading the source unearths interesting things: https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/ https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/

mananaysiempre 9mo ago
I kept expecting an exploit :) Something to poke at on a slow evening, I guess, though with the buffer in static memory it might be difficult.
- Deeg9rie9usi 9mo ago
  Exploiting this is close to trivial because the adjacent buffer contains the pw entry. So, you can control what the input is compared with. That way the password check can be bypassed without injecting code.
  - mananaysiempre 9mo ago
    Good point, thanks! The crypt() of the input, not the input itself, but guessing at the (PDP-11 assembly :/ ) code for crypt() a bit, it looks like it stops after 64 characters if it can’t find a null terminator before that, so 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345678901234567890123456789012345root:p3Y0ydAx: should work as an exploit, and indeed it does. (Arbitrary 64-character password, then 36 bytes to pad to the end of the 100-byte buffer, then the part of root’s /etc/passwd entry for said password until at least the second colon.)
- rst 9mo ago
  Well-known vulns are all over this code. For example, mkdir had a TOCTTOU which persisted into v7 (and I believe 2BSD); it was implemented as a setuid binary which did a mknod followed by a chown to create the directory. Code which invoked mkdir could set up a race replacing the root-owned directory, before the chown, with a link to something else -- which would then get chowned to the user running mkdir. The target had to be on the same filesystem as some writable directory, but on many installations of the day, a mkdir in /tmp followed by this race was good enough to get you ownership of /etc/passwd. This was finally cleaned up in 4.2bsd, when mkdir was made a single syscall which was guaranteed to alter only the particular inode it allocated.
mmooss 9mo ago
> the knowledge that a buffer overflow could be exploited for arbitrary code execution had not yet come of age. Meaning, people hadn't figured that out, or it wasn't a commonplace technique? They must have seen buffer overflows crash running software; it doesn't take much imagination to think about the next steps.
- dboreham 9mo ago
  Most computers did not exist in an adversarial environment at the time. Perhaps the most "adversarial" context would be: undergraduate timeshare use. So the mainframes of the day, which would be the typical platform for undergrad programming (if timeshare was even offered to undergrads in 1973) might be expected to be somewhat hardened to attacks of various kinds since undergrads trying to hack their grade higher, get more CPU time, etc, was a known thing. But Unix machines, and minicomputers in general, were not used for undergrad purposes. They were only available to be used by PhD candidates and other higher order beings. Those dudes had the root password anyway, so no need to harden the machine against their potential attacks. There was no networking to speak of, so no malicious traffic to worry about. The first worm didn't appear until the late 1980s. So if you had talked to a Unix sysadmin in 1973 (all...1 of them) they probably would understand the general concept of someone running a program that crapped onto kernel memory with the result they could have root privileges, but there would have been no plausible adversary around with any reason to mount that attack. Plus every cycle and every byte counted, so there would have been many more fish to fry before worrying about buffer overflow problems.
  - II2II 9mo ago
    > since undergrads trying to hack their grade higher Would student records even be stored on an unix system at the time? I am under the impression that Unix was very much a research operating system in the 1970's (either the subject of or a tool for). Administrative functions were more likely to be conducted with an IBM mainframe. (At least that is how it was when I arrived at university a couple of decades later, which I always took to be a legacy thing.)
    - 9mo ago

Reading the source unearths interesting things: https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/ https://sigma-star.at/blog/2025/12/unix-v4-buffer-overflow/

mananaysiempre 9mo ago

I kept expecting an exploit :) Something to poke at on a slow evening, I guess, though with the buffer in static memory it might be difficult.

Deeg9rie9usi 9mo ago
Exploiting this is close to trivial because the adjacent buffer contains the pw entry. So, you can control what the input is compared with. That way the password check can be bypassed without injecting code.
- mananaysiempre 9mo ago
  Good point, thanks! The crypt() of the input, not the input itself, but guessing at the (PDP-11 assembly :/ ) code for crypt() a bit, it looks like it stops after 64 characters if it can’t find a null terminator before that, so 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345678901234567890123456789012345root:p3Y0ydAx: should work as an exploit, and indeed it does. (Arbitrary 64-character password, then 36 bytes to pad to the end of the 100-byte buffer, then the part of root’s /etc/passwd entry for said password until at least the second colon.)
rst 9mo ago
Well-known vulns are all over this code. For example, mkdir had a TOCTTOU which persisted into v7 (and I believe 2BSD); it was implemented as a setuid binary which did a mknod followed by a chown to create the directory. Code which invoked mkdir could set up a race replacing the root-owned directory, before the chown, with a link to something else -- which would then get chowned to the user running mkdir. The target had to be on the same filesystem as some writable directory, but on many installations of the day, a mkdir in /tmp followed by this race was good enough to get you ownership of /etc/passwd. This was finally cleaned up in 4.2bsd, when mkdir was made a single syscall which was guaranteed to alter only the particular inode it allocated.

mmooss 9mo ago

> the knowledge that a buffer overflow could be exploited for arbitrary code execution had not yet come of age. Meaning, people hadn't figured that out, or it wasn't a commonplace technique? They must have seen buffer overflows crash running software; it doesn't take much imagination to think about the next steps.

dboreham 9mo ago
Most computers did not exist in an adversarial environment at the time. Perhaps the most "adversarial" context would be: undergraduate timeshare use. So the mainframes of the day, which would be the typical platform for undergrad programming (if timeshare was even offered to undergrads in 1973) might be expected to be somewhat hardened to attacks of various kinds since undergrads trying to hack their grade higher, get more CPU time, etc, was a known thing. But Unix machines, and minicomputers in general, were not used for undergrad purposes. They were only available to be used by PhD candidates and other higher order beings. Those dudes had the root password anyway, so no need to harden the machine against their potential attacks. There was no networking to speak of, so no malicious traffic to worry about. The first worm didn't appear until the late 1980s. So if you had talked to a Unix sysadmin in 1973 (all...1 of them) they probably would understand the general concept of someone running a program that crapped onto kernel memory with the result they could have root privileges, but there would have been no plausible adversary around with any reason to mount that attack. Plus every cycle and every byte counted, so there would have been many more fish to fry before worrying about buffer overflow problems.
- II2II 9mo ago
  > since undergrads trying to hack their grade higher Would student records even be stored on an unix system at the time? I am under the impression that Unix was very much a research operating system in the 1970's (either the subject of or a tool for). Administrative functions were more likely to be conducted with an IBM mainframe. (At least that is how it was when I arrived at university a couple of decades later, which I always took to be a legacy thing.)
  - 9mo ago