Comment by ButlerianJihad

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/...

In the Before Times, when I didn't have direct Linux experience yet, I was telnetted into my university's computer lab (as a non-root user) to do homework. I needed a newer version of GCC, and was resourceful enough to download, compile, and install it. A few days later I got called into the comp sci department to explain why I was hacking the shared server. I didn't know enough then to articulate how much I honestly didn't do anything malicious, but the sysadmin had evidence that I'd written files all over the place. I denied knowingly doing anything, but he had the proof. I was nearly on the edge of tears afterward out of fear of getting suspended for hacking. It was made clear that this was absolutely on the table.

I told a much more experienced friend what happened and he investigated. He dragged the sysadmin to the dean's office and told everyone loudly that the sysadmin was a dipshit who had made all of /usr world-writeable for who-knows-why, and from my shell history, it was clear that my `make install` of gcc had put it in /usr/local, the default --prefix. I'd "written files all over the place" because GNU tools default to installing in /usr/local, the sysadmin had deliberately made that possible, the logs showed that I'd done nothing more than download, build, and install an appropriate educational tool, the sysadmin was a dumbass and ought to quit, I was blameless, and that better be the end of it or it was going to get publicly embarrassing. My friend was the right kind of asshole to march into that meeting on my behalf: smart enough to prove that he was right, and aggressive enough to make it clear that the other party was undeniably wrong. I'm still grateful to him for that day.

This is how the system chills our speech, making us nice and compliant little workers. Putting some funny animation codes into your .plan wasn't doing anything wrong.

Meh. Sysadmins are dicks. The system is secure or it's not. Poking at the locks is not a serious threat.

I know a similar story of a sysadmin who did the same, but went into the lab and sat down next to the student. And then put his handgun on the table.

Power tripping assholes.

Source: I was a sysadmin.