Comment by mananaysiempre
8 days 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.
8 days 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.
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.
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
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.)
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.