💾 Archived View for zaibatsu.circumlunar.space › ~solderpunk › phlog › were-bringin-finger-back.txt captured on 2023-03-20 at 17:46:39.
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
We're bringin' finger back! --------------------------- It's a lively time in the pubnix scene! Things in circumlunar space are developing rapidly. See recent posts by slugmax[1,2] and visiblink[3] for updates on the Republic colony and our new XMPP server. Federation between the Zaibatsu and Republic is working smoothly, with email, IRC and BBS joining the two into a single user community, as was always the plan. We are also now exchanging email with other pubnix hosts, tying ourselves into the wider pubnixverse according to my two-tier structure philosophy[4]. It's an exciting time. Welcome to all the new sundogs at the Republic! This post is about another project to join all pubnixes together, which some of you may be aware of. The title says it all, really. We're bringin finger back! Yes, that's right finger, of RFC742. If you're a sysadmin-type, you possibly just broke out into a cold sweat. Finger seems to have a terrible reputation online these days with regards to security. Worse even than telnet, perhaps. I have read comments to the effect of "nobody who cares about security runs a fingerd" or "you're brave to run a fingerd in this day and age!". I honestly believe that in the context of a public access unix server this attitude doesn't make a lot of sense, but before I elaborate on this, a quick overview "for those who came in late". Finger is a very simple TCP protocol assigned well-known port 79. The gist of it is that you connect to a remote host, send a username followed by CRLF, and the remote host sends you back some information about that user and closes the connection. It's gopher-like in its simplicity. When I say "some information", I mean the contents of your GECOS field (the weird ancient personal metadata enshrined in the /etc/passwd file since the earliest days of Unix, which tells your full name, building, room number, and telephone numbers - if you opted to enter them when creating your account, of course) as well as the contents of some files in your home directory - ~/.project, which, by convention, was a relatively static file explaining what it was you worked on, in general, and ~/.plan, which was updated more frequently (perhaps at the start of each week) with more finegrained information, including details on where/when/how to find/contact you. All of this obviously harks back to the days when multi-user unix deployments were invariable at universities or the research department of large companies. It was basically a kind of distributed staff directory. If you're near a shell right now, you can finger yourself (ahem) by simply typing e.g. `finger solderpunk` to see the kind of thing we're talking about. On your local machine, it's very likely you'll see somewhere in the output "No plan", because ~/.plan files nowadays are pretty rare. Why would people freak out about running fingerd? I think a little bit of the hysteria comes from the fact that fingerd was one of the exploited pieces of software used to facilitate the spread of the infamous Morris Worm[5], back in the day. This is irrational - that attack was not based on some kind of protocol-level weakness in finger, but rather on a buffer overflow vulnerability in a common implementation of the time which, believe it or not, has been patched since the late 80s. At the end of the day, what fingerd mostly does is to accept a single query line over TCP, reads some files in a user's home directory, and send the contents of those files back to the client. If it's possible to write a secure HTTP server, it's possible to write a secure finger server. In fact, it's *easier* to write a secure finger server as a simple consequence of the protocol being far simpler than HTTP. The second and somewhat more valid concern is that some versions of fingerd will respond to an empty query line (just a CRLF over the wire and that's it) with a list of all the system's users, which some would argue could then be used to help attack the system. If you've ever run an sshd on the public internet and looked at your logs, you'll know that brute force attacks are a fact of life, and many of them use common firstnames as usernames. Running a fingerd that basically hands out valid usernames arguably makes such brute force attacks easier. Is this a practical threat to, say, the Zaibatsu? No. For one thing, password authenatication for ssh sessions is not allowed. It's private key or bust, and 1024-bit or longer keys are not practically brute forcable, not by a long shot. It doesn't matter if somebody knows a valid username, if they don't have that persons' key they are not getting in. There are no other network services running which require a username. One might argue that knowing a username is still of value to an attacker, e.g. if they find a vulnerability in gophernicus or the git server or something else we're running, knowing a username might be of some value in exploiting that. But this brings me by next point, which is that fingerd or no the list of usernames at the Zaibatsu is not a secret. They are literally all spelled out on the main gopher page, right there. This is also true at SDF, Grex and pretty much any other multi-user gopher host. It's true of just about any pubnix, even ones which don't offer gopher hosting - you can probably harvest usernames from the URLs of user pages at pubnixes which offer webhosting. Hiding usernames is counter-productive to the mission of a pubnix, so shying away from running fingerd for this reason makes no sense. The one legitimate reason I can think of to consider running fingerd scarier than running httpd is related to the privacy of your users. It's not a problem that standard fingerd implementations share GECOS information or .project and .plan - those are under the direct control of the user, so people can share as little or as much as they like (I don't think *any* user at the Zaibatsu has put their real name in their GECOS field). However, standard implementations also indicate whether or not a user is logged in or not, and if not when they last were, including, crucially, the IP address they (last) logged in from.