alt Hacker NewsSpeaking of finger, console logging, and the 90s: when I was a freshman in college I took a Pascal programming course. We were assigned accounts on a cluster of AT&T 3B2 systems running SVR3. The students only had access to a terminal lab; the servers were upstairs, out of our reach.
There was no disc quota or significant restriction on the resources available to us, so I became a video game mogul. I found all the freeware download sites, and I became an expert on portability, tweaking and compiling game software to run on our idiosyncratic system.
As students, we made extensive use of "finger", "w", "who", and "write". We also knew the existence of "wall" and the like. So it was de rigeur for us all to write a little something into our .project and our .plan files. I took it much further, and discovering VT100 escape sequences, produced an animated .plan file which erased and mutated some of the immutable datapoints displayed, such as replacing my $HOME directory with "/" and some script-kiddie flexes like "I have root access... you know!"
Subsequently I explored the system extensively and eventually found /etc/passwd, and for reasons, attempted to "su" to every single account I found in there, most of them being system maintenance accounts. Due to logging and auditing, of course, these blatant, brazen failures captured the attention of the unseen administrator.
I received an email that made my blood run cold. The admin (and I still remember his name 37 years later) told me everything I had done in detail, and said that claiming "root access" was equivalent to telling airport officials that I was carrying a bomb. And there were no academic sanctions or threats in this email, but his veritable omniscience and dead-serious tone made me reconsider many of my life choices at the age of 19. Today, I am thankful for this guy putting things into perspective, that Unix was not just a huge game of Zork or Nethack, and he definitely inspired my career goal as systems admin.
Hehe, I know I managed to undo the damage I caused, but I'm sure my activity was logged and noticed by the sysadmins at the time. Ironically, after graduating I later became a sysadmin at another department at my university and told them about the particular thing I'd exploited.
But, anyway this was on SunOS and specifically some Sun4c machines with a PROM password. I discovered a couple of new machines were put into the labs without a PROM password, so you could press STOP-A and get into the forth debugger, and read/write system memory. This seemed interesting, but I wasn't sure what I should be changing.
Then one day, I was reading some documentation, and there was a system call [1] that returned a pointer to some information about the current process (or maybe it was for a specific pid), and one of those fields was marked as reserved. I discovered that the field seemed to contain some kind of pointer, but I couldn't de-reference it, so I guessed it was something in kernel space, probably the information about the task needed for the task switcher. This also seemed interesting!
Using the PROM monitor to dump memory starting at that address gave a lot of interesting stuff, and at something like offset 22 there was a pointer to another structure and dumping the memory at this one showed my uid and gid, IIRC the uid was offset 6. Sure enough, overwriting the uid changed the euid of my process.
So, I could reliably get root on any machine without a PROM password by running my program, using the PROM to read the contents of the address it printed out, add 22, use the PROM to read that address, add 6 and write a zero to that address. (Assuming they are the correct numbers after 30 years of brain rot).
So, anyway, I had a bit of fun locally, and noticed that there was a memory mapped file that let you read the PROM contents. I then decided that I wanted to examine this on a machine that had a PROM password set, but this was harder than I expected. My initial plan was to rsh into the other machine as root, but that was forbidden by policy (and this would have been logged). I then thought about creating a setuid script with my new found root access, but that was thwarted as each machine had NFS mounted with root-squashing and their own local root partition. So, I decided I needed to create an additional "system" user in /etc/passwd with a password I knew (because that owned the binaries and wouldn't have root squash). The specifics of what went wrong I forget now because things rapidly got stressful so a lot of it became a blur, but the long and the short of it was that I managed to completely delete the NIS password file on that machine and so I couldn't log into it any more to attempt to undo my damage. However, I discovered that the non-NIS passwd file was still intact, and so I had to use my previous PROM trick to hack the "bin" user on a different machine, which allowed me to rsh as "bin" into the machine I'd just trashed (and that would definitely have stood out in the logs). Once I had a shell as "bin" on that machine, I was able to use the PROM trick again to upgrade that to a root shell and undo the damage I'd done before.
Some time later, there was some other root exploit knocking around, and I used that on a machine with a PROM password set, and discovered I could easily read what the password was just by reading that memory mapped file. As luck would have it, every machine had the same PROM password, and so from that point I could always have gotten root if I wanted it, but was always too worried about causing other damage that I never actually used it.
However, when I later became a sysadmin at the university, the other sysadmin was very confused one time when I did the same hacking root trick after he'd managed to mess up something similar on the root partition of a couple of machines and he thought he'd have to reinstall them all!
I just did STOP-A and entered the PROM password that he'd never told me, and did the same thing I'd done before and just said "yeah, we should probably change this password as it's the same as it was 2 years ago". The process of changing the password was annoyingly fiddly as the PROM password change tool was designed to only work on the console, which is why they'd never changed, so I wrote something to pretend to be an actual TTY so I could update all 100 odd machines remotely via rsh instead of logging on at the console of each of them. Fun times!
[1] I have some recollection it was an ioctl, but I'm a bit hazy on that now as it was over 30 years ago. I suspect it was the SunOS 4.3 version of the prpsinfo structure described in this: https://www.typewritten.org/Manual/Sun/SunOS/5.1/SPARC/man4/...