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?
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.
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.
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.
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.
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.
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.
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.
18 comments
[ 2.5 ms ] story [ 52.8 ms ] threadAn 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
It's really not bad, and you can use it for scripting like sed, but it's clunkier.
# ... sound of crickets ...
Wanna see me do it again?
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.
> 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.
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.
ttybuf[2] =& ~010;
Which is another bug.