Finger: the 1971 social network that never died(en.andros.dev) |
Finger: the 1971 social network that never died(en.andros.dev) |
Such good memories. I think my whole career has been built around chasing the feeling I had when making that gaming site.
[1] https://icculus.org/~icculus/
[2] https://icculus.org/finger/icculusMy GF when I was first learning these names was convinced the Unix principals did all this quite deliberately and "finger" was her headliner argument. Evidently, even in 1971 someone complained: https://blog.robertelder.org/intro-to-pinky-command/ (relevant to that source, Usenet/Net News/mailing lists may be another social network which never exactly died and even today LKML, zsh-workers, etc. are main communication avenues).
Type your current status in a bar.
And the thing that aggregates them? Twitter.
People like to peek into what others are doing.
Also worth checking: finger ring@thebackupbox.net
I 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.
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.
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/...
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.
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.
It's his fault, not yours, that he wasted paper.
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.
this scenario still happens today.
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.
Maybe the answer is to define a plan base URL as a DNS TXT resource on a particular DNS domain. For instance, I added the string `< plan https://bi6.us/PL/ >` as a TXT resource at _plan.hamrick.rocks. It should now be a trivial task to write a program called `finger-ng` that when I type `finger-ng meadhbh@hamrick.rocks`, it queries the TXT record at `_plan.hamrick.rocks`, extracts the plan base URL and then retrieves and displays a text document found at `https://bi6.us/PL/meadhbh%40hamrick.rocks`. I guess you could serve up a text/plain, text/html or even image/avif if you wanted to.
This, of course, assumes `bi6.us` is set up to allow me to update that file, but this is also straight-forward. Anyway, check back in a couple days and I'll have some code and I'll write the RFC/ID next week.
EDIT: I wrestled with apache and got it to understand files under www.bi6.us/PL/ should be served as text/dsd+plain, so you can hit `HTTPS://BI6.US/PL/MEADHBH%40HAMRICK.ROCKS` and get something that looks legit. And sure enough, HTTPS://BI6.US/PL/MEADHBH%40HAMRICK.ROCKS encodes to a smaller QR code than https://bi6.us/PL/meadhbh%40hamrick.rocks. (Though it looks like the HN text beautifier doesn't automagically produce links for URLs beginning with upper-case HTTPS.)
EDIT EDIT: Hmm... still doesn't say anything about privacy. What if you wanted to have a different _plan file for friends, a _plan file for family and a _plan file for co-workers? Clearly deep thoughts must be thunk.
Also if you wanted a .plan for different people you would code your own server as in the article and tie it to a different “user”. The original server ties .plan files to username home dirs but there’s nothing stopping you from changing how that effectively works on your own server.
The start page exists because finger has no discovery layer. finger @host lists users. lookit makes that list selectable, so you can wander a server instead of querying one address at a time.
I just released a v0.2 beta, feedback welcome: https://github.com/jonathandeamer/lookit/releases/tag/v0.2.0...
Perhaps a global database or a parallel project like a search engine focused on fingering is needed. The sources are scattered, and clients like yours would greatly benefit from that.
I'd also like to mention that if you have Emacs, I also have my own client: https://git.andros.dev/andros/efinger.el
Was definitely an inspiration for lookit. And yes, a search engine would be cool!
Couple hours later, i get pinged in Teams by someone in the security group who, who was flagged for my activity. No harm, but he said that they watched it because it had been used for malware. Said I shouldn't use it unless i had some business need, would need to do a request apparently.
My friend heard about this and fingered me 10,000 times in 5 minutes, and the computer science department's file server went down and I almost got fired.
https://github.com/ESWAT/john-carmack-plan-archive/tree/mast...
(1) Looks like great reading. (2) Who compiled the archive, and how? This feels like one of those situations where a person records the evening news onto VHS for decades; except here they were running finger every day for decades? (3) Is there a more mobile-friendly way to browse it?
AI smell?
The slop-machines write the way they do because they have been fed material, and they then spew that back out. So any writer whose style looks a little different, eccentric, or unique may find that the slop-machine's stochastic processes lead them into a state where the pool of possible continuations is small enough that the mimicry is strong.
My wife's writings have recently been labelled as "probably AI" ... and we are livid.
But there's nothing we can do except write in a style that is not truly our own, just to avoid the inaccurate "slop identification" algorithms from smearing us.
Vile machines.
/rant
Also... I seem to remember more than one security issue with stock `fingerd` at the time. After the second or third flaw in fingerd, I think it was banned (as much as it could be) from machines at Convex. By the time I made it to IBM/AIX, it was a serious no-no to have running on your machines.
It still does (at least on my MacBook):
$ finger myusername
Login: myusername ...
...
No Mail.
No Plan.Thx for the mention blogger!
https://blog.alexellis.io/the-90s-unix-command-fell-out-of-f...
Still, something like a masked identd used for masking system usernames for irc would go a long way to break the link between actual user accounts and display names for finger.
Yes the code still exists, and it still works if you run it, but that's true of almost any old software.
Just because it’s not widely used doesn’t mean it’s dead.
Just one cell.
Heck, you could probably make a little program for HN to use the about box as the service and achieve the same thing.
Come to think of it I setup my first “date” (more like a hookup) over unix talk.
We had a legit proto social network going, all over telnet!
What I find funny is how an Estonian proverb/saying would fit here quite nicely: “don’t try to teach your grandfather how to have sex.” In this case, the grandfather didn’t need teaching - it was molded by the era into what was necessary.
"Fingering was huge at my university" is, in the UK, very true, but I feel that's not the context you're using it in!
[1] - https://nochan.net/b/Internet-Crap/20260527-DNS-A-Replacemen...
The easiest modern solution would probably be git pulling from an Onion address (running git daemon so it's read only). Then, when your machine is on, people that want updates would just
git pull git://abcdef1234567890.onion/fingerfood.git
some 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!)
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.
So I got my hands on the root passwords for all the office servers. In particular, there was a SPARC 2 that had both "intranet" and external functions. I pored over manual pages for awhile and I discovered this amazing concept called "C2 security". It described security manuals which I could not obtain or read and it promised to tighten up the system according to federal regs. How could I resist?
So I found the SunOS command called something like "C2conv"; I su'd and I ran it. Much to my horror the /etc/passwd file got sort of ripped apart into /etc/shadow (which was a very unfamiliar concept in 1994) and the system became sort of non-functional. Also to my exploding-head level horror, there was literally no such thing as "C2unconv" because it was a one-way conversion. So I had to sort of manually pick through the changes and fix it up before my boss really noticed. And I did get it working again. But I was terrified by that.
Obviously, for our operational network, working with telecoms and large-scale customers who leased T-1s and so forth, we had rigid policies on scheduled maintenance, customer notification, outage windows and so forth. I really had no clue if any of that applied to my sysadmin job and the servers under my care. It was a wild ride during the "dot-com boom", I tell ya.
I could Google but it's more fun to vaguely remember.
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.