8/18/2026 at 1:43:57 PM
In the mid-90s I taught a night class on Unix, and was experimenting with shell scripts from The Unix Programming Environment. There was an example using a loop and the who command to alert you when someone logged onto your local system. My cousin was a professor at a university several states away, and we had already figured out the talk command. So I decided to expand the examples in the book to use finger. By parsing the reply, somehow I could tell if my cousin was logged on, and I would send myself a notice. There was an ISP in the same building, and one day the ISP engineer came to visit me with a stern look. He asked, "By any chance are you sending a finger command every two minutes to this university's mainframe?" I proudly answered, "As a matter of fact, yes, I am!". I eagerly got out my Unix book to show him what I was doing. He just said, "Stop doing that. They have a system console logging program that has churned out dozens of pages of paper printouts because of you". I sheepishly acknowledged my mistake and quit running the script.by seoulbigchris
8/19/2026 at 6:42:38 AM
> finger [...] dozens of pages of paper printoutsI know just the poetry to go with that story:
The Moving Finger writes; and, having writ,
Moves on: nor all thy Piety nor Wit
Shall lure it back to cancel half a Line,
Nor all thy Tears wash out a Word of it.
by Terr_
8/19/2026 at 9:29:58 AM
Bravo!by poetaster
8/18/2026 at 1:57:17 PM
Speaking 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.
by ButlerianJihad
8/18/2026 at 3:16:51 PM
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/...
by ralferoo
8/19/2026 at 7:09:38 AM
What fun. War stories like this are what keep me coming back to HN.by _jackdk_
8/19/2026 at 3:42:08 PM
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.
by kstrauser
8/19/2026 at 12:53:16 PM
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.by inigyou
8/19/2026 at 1:37:20 PM
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.
by qarl2
8/19/2026 at 4:51:29 PM
One of the more ridiculous stories I remember from Uni was sysadmins getting very upset that students were fork bombing the server. But... it was from the students in the systems programming class that were just learning about fork/exec, and bugs happen... I thought it was the most ridiculous thing ever.Also, this was the late 90s and while you could get linux running, all the servers were Unix, and the profs made it very clear any issues between differences between Linux and Solaris were ours to deal with... so we were essentially forced to login to their servers. We are truly our own worst enemy sometimes.
by kevstev
8/19/2026 at 5:47:13 PM
I still remember being "invited" to a meet-and-greet with the VP of Tech at my college after a fork bomb run amok. 17yo me was sure my academic career was at an end. He let me sweat for a few of minutes and then smiled and offered me a job. <whew>by makr17
8/19/2026 at 8:37:09 PM
That's a good sysadmin. They are few and far between.by qarl2
8/19/2026 at 5:02:06 PM
A gun? Lmaoby 2snakes
8/19/2026 at 5:22:42 PM
Yeah. He really enjoyed his newfound authority.by qarl2
8/18/2026 at 2:59:04 PM
I was sure this story was going to end with your script causing chaos by calling finger in a busy loop. But every 2 minutes! Even in the 90s, that's a pretty mild amount of network traffic.by quietbritishjim
8/18/2026 at 6:28:04 PM
I think automatically printing the system console log to paper is the real villain in that story.by stronglikedan
8/19/2026 at 7:57:19 AM
once i saw a guy run a pentest and a box was doing that. it printed an entire vulnerabilityscanner output verbatim all the bytes received o.O guy appearently got handed like 100m of paper with a request to pls not scan _that_ port :'Dsome people had these setups and just never saw a lot of traffic because the boxes werent broadly routed on the internet etc. or internal.
now with all the scans and automated spamming by parties its totally unthinkable. most of my server bandwidth despite my efforts is going to this.. (thankfully down pay for that per bytes anymore!)
by saidnooneever
8/19/2026 at 12:51:49 PM
Printers used to, and maybe still do, have a port open that if you connected to it and send some ASCII text it would print that text. Complete with formatting codes like form-feed to switch to a new page.by inigyou
8/18/2026 at 6:12:18 PM
The grey beards in the mid-90s cut their teeth on much more constrained systems! The web crawling these days probably has all the ones who have passed spinning rapidly in their graves.by transitorykris
8/19/2026 at 7:45:42 AM
Paper companies would rejoice at the idea of OpenTelemetryby boomlinde
8/19/2026 at 12:50:08 PM
This is what teaches people not to do cool things.It's his fault, not yours, that he wasted paper.
by inigyou
8/18/2026 at 7:20:24 PM
If running finger causes a paper printout, the issue appears to be with the latter.by mixmastamyk
8/19/2026 at 2:45:37 AM
It may seem that the admins were wrong to criticize the fingerer for the voluminous output, but if you think about it, paper logging was a very pragmatic security and auditing measure in those days.We had a lot of printers around the labs in our university, and they were high-speed, high-capacity. And in the earliest days of multi-user and time-sharing, the hardcopy terminal was actually the default, where the fabled "glass terminal" came along later!
So you have a highly secure system and it's outputting important log entries that may need to be examined later, in the case of a malfunction or a compromise attempt. So you send the most important output to your printer, and you get an offline, immutable audit trail to back up your most important log files.
That seems like a very routine and pragmatic step. In the intervening decades, there were many logging strategies, and many of them admitted for "covering your tracks" by hackers who could erase logs and destroy evidence if the admins weren't careful.
But again, if a 2-minute "finger" interval was causing a paper log overflow, the admins could have mitigated that, but perhaps they were justified in telling the kid to knock off the frivolous resource usage.
However, as I worked for an ISP back in those days as well, I can tell you that log overflows were crazy-making. We had a particular system that acted as primary DNS for many customers. And many customers who were brand-new to the Internet and brand-new to this DNS thing were not real good at configuring it according to standards. And so we had a NOC with projection monitors that monitored system status in various ways, and one of them was tailing our syslog file.
And all day long I kept seeing DNS errors. "Lame delegation" was the winner overall, but there were so many. I was so young and had no privileges or knowledge to fix them. But I helplessly watched them scroll, knowing there were issues, slowdowns, and inefficiences that I couldn't solve for them. Sorry guys.
by ButlerianJihad
8/19/2026 at 3:30:33 AM
I could see that, thanks. However OP mentioned the mid-nineties and I was working then. No one was printing out logs or saying "glass teletype" at that time. Twenty years earlier, sure, or maybe some elderly curmudgeons working at a conservative bank/govt installation perhaps.To answer the sibling post below, I had a 1GB drive at home around that time, enough to store text logs cheaply. Logrotate is apparently from 1996.
by mixmastamyk
8/19/2026 at 8:04:59 AM
people in 2026 still print out logs like this on rolls lf paper. cant be tampered. log tampering is a big issue for forensics. most programs do not have cryptographically verifiable logs.... and yes that wont be for all systems and all types of logs. but will take shittons of paper still to keep the records going back up to like 7+ yearsby saidnooneever
8/19/2026 at 9:50:04 AM
we're talking about logs for finger here, not bank transactionsby anonreplier
8/19/2026 at 5:25:51 PM
FINGER IS VERY IMPORTANT!by qarl2
8/19/2026 at 5:28:04 PM
ah my bad :D. i wasnt talkin about bank transactions but yeah :p not finger logs either haha.by saidnooneever
8/19/2026 at 7:11:15 PM
Well, the brainchild of YC Founder Robert Morris, the Morris Worm, exploited a zero-day in fingerd, so yes, after 1988, fingerd was extremely important for network security.by ButlerianJihad
8/19/2026 at 9:55:47 PM
I'm not sure a hard copy would have particularly helpedby anonreplier
8/18/2026 at 8:01:47 PM
early 90s paper may have been cheaper than digital storage I think?by kolinko
8/19/2026 at 10:58:06 AM
It may be a case of needing write only logging, I always think of the nuclear power station logging all events to the line printer, But I can see a NOC doing the same, How finger ended up triggering it would probably be a fascinating case study of early innocent decisions getting ossified into the infrastructure.by somat
8/19/2026 at 12:01:39 PM
Handier to access when something is wrong, certainly.by Sharlin
8/19/2026 at 12:52:08 PM
Why do they need any storageby inigyou
8/19/2026 at 8:03:21 AM
depends, if its a printer with port 9100 open, or a system that forwards traffic to that, then it will chunk it ontop paper.this scenario still happens today.
by saidnooneever
8/19/2026 at 10:03:28 AM
Indeed, it's 2026 and people are still putting HP port direct - directly on the internet https://www.shodan.io/search?query=hp+printer+9100by _joel
8/20/2026 at 2:11:26 AM
I was fingering Stacy L. from my account rohan.sdsu.edu to her accoun at Occidental college and got exactly the same outreach from Chris P. at SDSU where he politely asked me to "stop fingering Stacy". The admin from Occidental offered me a shell on their machine so i could just last her... Good times. Found my comment from 2024 on the same topic - https://news.ycombinator.com/item?id=41907360by bks
8/19/2026 at 12:17:48 PM
We had a VMS system at Uni in the 90s and we could tell what lab someone was in via the Finger command. Apparently it caused significant load on the system.by nl
8/19/2026 at 8:31:16 PM
The one time I got locked out of the university's computers, around 01994, it was for doing this.Someone, I think ncftp's Mike Gleason, had written a program called `ison` which would run in the background, fingering a given user@host every minute; once the response indicated that the user was logged on ("was on", thus the name), it would print a message to your terminal and exit. If you logged off first, it would exit automatically.
There were three girls I would regularly chat with on IRC, so I put `ison` invocations into my .tcshrc (or maybe my .profile, I forget), so that I could hop on IRC whenever one of them logged on, or `talk` to them if they weren't on IRC. But I thought a minute was unreasonable latency, so I reduced the interval to 15 seconds; I forget if this was a command-line flag or a modification to the source code.
So, when I would dial in from home, running a single Unix shell, I would spawn three `ison` processes, which would each finger every 15 seconds. Unbeknownst to me, `inetd` forking and execing `fingerd` on the remote hosts in question, followed by `fingerd` checking all the relevant information, took on the order of a whole second of computation — one of the remote hosts was a VAX, one was a Sun workstation (probably a Sun-4, but maybe a decrepit old Sun-3), and I forget what the third one was; each was serving between ten and sixty concurrent interactive users, as I could see by fingering @host. So, at this point, I was unintentionally making these machines noticeably slower for their everyday users.
However, the university also had computer labs full of X-Terminals running X-Windows. And the way you use X-Windows (then and to some extent even today) is that you open terminal-emulator windows with shells in them so you can run your commands. And my university had actually about a dozen compute servers for use by any of the students, which were mostly DECStation 3000s, but later on also included some RS/6000s. Typically some of these machines would be more overloaded than others, so you would open shells on several of them — either by opening xterm windows on them, or by telnetting or rlogining from one to another, this being before the adoption of SSH. So it was not terribly uncommon for me to have 5–15 shells open on various computers in the computer center.
Each of these shells had its own associated `ison` process, and when one of my friends would log on, over the next 15 seconds, all of those `ison` processes would exit; so, too, if I logged out of my session. But, when they weren't logged in, I would be launching as much as one `finger` request per second split across many different hosts, a quantity which amounted to a distributed denial of service attack on the remote host.
My first clue that something was wrong was that, one day, I attempted to log in, only to be confronted with a notice that my account had been locked, and to please contact the security officer at the computer center. I just about wet my pants.
The system administrators at the other universities had apparently tracked down the sporadic unusability of their public Unix hosts to high load from many concurrent `fingerd` processes, logged the sources of the `finger` requests, discovered that they were coming from a variety of hosts at my university, and contacted the system administration staff there, who I believe then added logging to `finger`. But `ison` didn't invoke `finger`; it made the `finger` requests directly, and there wasn't a straightforward way to add logging to the `connect()` system call (both Ultrix and AIX were proprietary, and I believe source code was unavailable — and recompiling libc might have seemed like an extreme and risky measure).
So, as I understand it, the way they figured out what was going on was incident response — when their machines became unusably slow, the sysadmins at the other universities would telephone the sysadmins on my university, hopefully telling them which hosts were DoSing them, and the sysadmins at my university would then log into those hosts and try to figure out which process was responsible. Often, though, by the time they looked, I would have already logged out.
This combination of using a C program I'd compiled myself to launch the "attack", distributing it across various hosts, and running the "attack" at unpredictable times of day and stopping after apparently random intervals, added up to the profile of a sophisticated, malicious computer-security threat actor, in their minds — although I found out later that using `bash` as your login shell was also sufficient for that. In a long, heartfelt conversation, I was apparently able to convince the security officer that my "sophisticated attack" was entirely unintentional and that, indeed, I had no idea that it was causing any sort of problem, and he unlocked my account. But thereafter I had the reputation among the sysadmins of being a "hacker".
A few years later, one of the computer center staff from that time was working as a sysadmin in Silicon Valley, and he recommended me for my first sysadmin job at a time when I was washing dishes in a Midwestern café for a living. Genuinely changed my life for the better. So I guess that reputation wasn't an entirely bad thing.
by kragen