Community Hub0 Subscribers
Community hub
Finger (protocol)
View on Wikipediafrom Wikipedia
In computer networking, the Name/Finger protocol and the Finger user information protocol are simple network protocols for the exchange of human-oriented status and user information.
Name/Finger protocol
[edit]The Name/Finger protocol is based on Request for Comments document RFC 742 (December 1977) as an interface to the name and finger programs that provide status reports on a particular computer system or a particular person at network sites. The finger program was written in 1971 by Les Earnest who created the program to solve the need of users who wanted information on other users of the network. Information on who is logged in was useful to check the availability of a person to meet. This was probably the earliest form of presence information for remote network users.
Prior to the finger program, the only way to get this information on WAITS was with a WHO program that showed IDs and terminal line numbers (the server's internal number of the communication line over which the user's terminal is connected) for logged-in users. In reference to the name FINGER, Les Earnest wrote that he saw users of the WAITS time-sharing system run their fingers down the output of the WHO command.[1][better source needed]
Finger user information protocol
[edit]The finger daemon runs on TCP port 79. The client will (in the case of remote hosts) open a connection to port 79. An RUIP (Remote User Information Program) is started on the remote end of the connection to process the request. The local host sends the RUIP one line query based upon the Finger query specification, and waits for the RUIP to respond. The RUIP receives and processes the query, returns an answer, then initiates the close of the connection. The local host receives the answer and the close signal, then proceeds to close its end of the connection.
The Finger user information protocol is based on RFC 1288 (The Finger User Information Protocol, December 1991)[2]. Typically the server side of the protocol is implemented by a program fingerd or in.fingerd (for finger daemon), while the client side is implemented by the name and finger programs which are supposed to return a friendly, human-oriented status report on either the system at the moment or a particular person in depth. There is no required format, and the protocol consists mostly of specifying a single command line.
The program would supply information such as whether a user is currently logged-on, e-mail address, full name etc. As well as standard user information, finger displays the contents of the .project and .plan files in the user's home directory. Often this file (maintained by the user) contains either useful information about the user's current activities, similar to micro-blogging, or alternatively all manner of humor.
Security concerns
[edit]Supplying such detailed information as e-mail addresses and full names was considered acceptable and convenient in the early days of networking, but later was considered questionable for privacy and security reasons.[citation needed]
Finger information has been used by hackers as a way to initiate a social engineering attack on a company's computer security system. By using a finger client to get a list of a company's employee names, email addresses, phone numbers, and so on, a hacker can call or email someone at a company requesting information while posing as another employee.
The finger daemon has also had several[citation needed] exploitable security holes crackers have used to break into systems. For example, in 1988 the Morris worm exploited an overflow vulnerability in fingerd (among others) to spread.[3]
For these reasons, by the late 1990s the vast majority of sites on the Internet no longer offered the service.[citation needed]
Application support
[edit]![[icon]](https://en.wikipedia.org/wiki/File:Wiki_letter_w_cropped.svg){kind=small} | This section needs expansion. You can help by adding missing information. (January 2011) |
It is implemented on Unix (including modern FreeBSD and macOS), Unix-like systems (such as Linux), and current versions of Windows (finger.exe command). Other software has finger support:
See also
[edit]References
[edit]- ^ Earnest, Les (20 February 1990). "Origins of the finger command". Newsgroup: alt.folklore.computers. Usenet: 1990Feb20.023931.13825@cs.rochester.edu – via Colbath, Sean.
- ^ "The Finger User Information Protocol". IETF. December 1991. Retrieved 15 December 2025.
- ^ Spafford, Eugene (8 December 1988). "An analysis of the worm" (PDF). Purdue University. Retrieved 10 June 2021.
| File system | |
|---|---|
| Processes | |
| User environment | |
| Text processing | |
| Shell builtins | |
| Searching | |
| Documentation | |
| Software development | |
| Miscellaneous | |
| |
Finger (protocol)
View on Grokipediafrom Grokipedia
/W) for expanded output, support for forwarding queries to other hosts (e.g., user@host1@host2), and comma-separated multiple usernames, though implementations vary in handling site-specific extensions.[1]
Despite its utility in early internet communities for social discovery—often described as an early form of "social software"—the protocol's disclosure of potentially sensitive user data raised significant privacy concerns from the outset.[1] It gained notoriety in 1988 when the Morris worm exploited a buffer overflow vulnerability in popular implementations of the finger daemon (fingerd), contributing to the worm's rapid spread across thousands of UNIX systems and marking one of the first major internet-scale security incidents.[3][4] Additional risks include denial-of-service attacks via recursive queries and reconnaissance for unauthorized access, prompting RFC 1288 to recommend configurable restrictions like disabling global user lists or query forwarding.[1][5]
Today, the Finger protocol is largely obsolete and rarely deployed in production environments due to these security and privacy issues, with modern alternatives like WebFinger (RFC 7033) offering HTTP-based discovery of user information in a more controlled manner.[6] While some legacy UNIX-like systems and tools (e.g., the finger command in Linux) still support it for historical or niche purposes, widespread disabling of finger services on firewalls and hosts has rendered it ineffective for most practical use.[7][5]
History
Origins and Development
The Finger protocol originated in 1971 when Les Earnest, a researcher at Stanford University's Artificial Intelligence Laboratory (SAIL), developed the initial Finger program for the WAITS operating system.[8] This tool was designed to deliver user status reports, addressing the need for researchers working irregular hours to quickly identify colleagues' availability without relying on cryptic system outputs.[8] WAITS, a time-sharing system running on PDP-10 computers at SAIL, supported collaborative academic environments where such information facilitated both professional and informal interactions.[9] The name "Finger" drew inspiration from the common gesture of users physically running their fingers down the lengthy, abbreviated output of the existing WHO command on WAITS terminals to locate specific individuals.[10] Earnest enhanced this by creating a supporting database that translated user IDs and terminal codes into readable details, such as full names, physical locations, and idle times—allowing users to gauge if a colleague was likely present for in-person discussions.[8] The program quickly gained popularity within SAIL, evolving to include optional .plan files for users to note their whereabouts or schedules.[8] In its early implementation, Finger served as a lightweight extension or replacement for the WHO command, focusing on basic queries for logged-in users, connection durations, and system load indicators. Deployed initially as a local tool in the resource-constrained setting of SAIL—a key ARPANET node connected in the early 1970s—Finger exemplified the ad-hoc innovations in academic and research computing. The first networked implementation, inspired by the SAIL program, occurred at MIT in late 1977 or early 1978.[1]Standardization
The Finger protocol was first formally specified in RFC 742, titled "NAME/FINGER Protocol," published on December 30, 1977, by K. Harrenstien of SRI-KL.[2] This document defined the basic query-response mechanism for retrieving user information from remote hosts, establishing a simple client-server interaction over TCP where a client connects to a server, sends a command line, and receives a response containing details such as user status, login times, and optional messages.[2] RFC 742 introduced support for querying individual users or listing all online users, with responses including references to user-specific "plan" files for custom messages, and it assigned the protocol to TCP port 79 (decimal, equivalent to octal 117).[2] RFC 742 was obsoleted by RFC 1288, "The Finger User Information Protocol," published in December 1991 by David Paul Zimmerman of Rutgers University.[11] This update refined the protocol to enhance interoperability across diverse implementations, addressing ambiguities in the original specification while preserving compatibility with existing systems.[11] Key enhancements in RFC 1288 included formalized support for query formats such as a null line ({C}) for listing all users, a username ({U}) followed by {C} for specific user details, and the /W or {W} option for verbose mode with expanded output like office locations and phone numbers; allowance for longer response lines beyond the 80-character limit implied in early systems; and explicit handling of plan files as optional administrator-controlled inclusions in responses.[11] It also clarified line termination with carriage return-line feed (CRLF) sequences.[11] These RFCs played a pivotal role in standardizing the Finger protocol within the early Internet community, facilitating its adoption on hosts running systems like BSD UNIX, ITS, and WAITS by providing a consistent framework for user information exchange.[2][11] The assignment of TCP port 79 in RFC 742, reaffirmed in RFC 1288, ensured reliable network addressing and contributed to the protocol's widespread integration into Internet infrastructure during the 1980s and early 1990s.[2][11]Technical Overview
Protocol Operation
The Finger protocol utilizes TCP as its transport layer on port 79 (decimal) to enable reliable, connection-oriented communication between clients and servers.[12] In the client-server architecture, a client initiates the process by establishing a TCP connection to the server's designated Finger port, where the server-side daemon, typically named fingerd or referred to as the Remote User Information Program (RUIP), listens for incoming requests. The client transmits a plain-text query over this connection, prompting the server to process the request by accessing local system resources, such as the user database in /etc/passwd on Unix-like systems, to gather relevant information. The server then streams the response directly to the client in an ASCII format terminated by carriage return and line feed (CRLF) characters, after which the server signals the closure of the connection, and the client responds by closing its end.[12][13] This operational flow—encompassing connection setup, query transmission, server-side processing via the fingerd daemon, response streaming, and connection termination—supports a straightforward, session-based exchange designed for efficiency in retrieving user-related data without maintaining persistent state.[12][14] As specified in RFC 1288, this mechanism ensures the protocol's simplicity and reliability for its intended purpose.[1]Query and Response Formats
The Finger protocol uses plain ASCII text for queries, transmitted over a TCP connection on port 79. A query consists of a single line ending with a carriage return and line feed (CRLF), which can be empty (null line) to request a list of all online users or contain a username to query information about a specific user. Optional modifiers, such as "/W" placed at the beginning, request verbose output including additional details like full name, idle time, and login time. For remote queries, the format supports appending "@hostname" after the username, allowing forwarding to another host, though implementations may limit recursion to prevent abuse.[1][15] Responses from the server are multi-line, human-readable ASCII text streams, terminated by a final CRLF after the last line, with no fixed binary structure to ensure compatibility across systems. For a null query, the response provides a short-format list of all logged-in users, typically including fields such as login name, real name, terminal identifier, and idle time in a compact, tabular-like arrangement. A username query elicits a long-format response with more detailed information, such as login name, real name, office location, phone number, current login time or last logout, mail status, and optionally the contents of user-specific files like .project or .plan, which contain project descriptions or personal messages. The exact fields returned are implementation-dependent but must include the user's full name; additional details like directory path or shell are optional.[1][15] The "/W" option, originating from early implementations like ITS systems, triggers the long format even for null queries, expanding the output to include idle times and other verbose elements, though servers may ignore it if not supported. Queries without options default to short format, and the protocol lacks any authentication or encryption mechanisms, relying solely on the plaintext exchange for simplicity. Remote queries (e.g., "user@host") are handled by forwarding the subquery to the specified host, with the response prefixed by the remote server's output.[1][15] Error responses are not strictly formatted but are typically brief text messages indicating issues, such as "No such user" for invalid usernames, "User not logged in" for offline users, or "System status unknown" for connection refusals; site administrators often customize these for clarity. If forwarding is disabled on a remote host, the response may state "Finger forwarding service denied," while a null query refusal might return "Finger online user list denied" to protect system resources.[1]Example Query and Response
Short Query (local user list):<CRLF>
Login Name TTY Idle Login Time
pirmann David Pirmann *ttyp0 <1 Nov 10 09:15
smith John Smith *ttyp1 5:23 Nov 10 08:42
/W user<CRLF>
Login name: user In real life: Example User
Office: Room 123, x4567 Phone: 555-0123
Directory: /home/user Shell: /bin/sh
On since Mon Nov 10 10:00 (PST) on tty1 from localhost
No Mail.
No Plan.
Security Issues
Known Vulnerabilities
One of the most notable vulnerabilities in the Finger protocol's fingerd daemon was a stack-based buffer overflow exploited by the Morris worm in November 1988.[16] This flaw allowed remote code execution by sending oversized queries that overrun a 512-byte buffer allocated in the fingerd source code on VAX systems running 4.3 BSD.[17] Specifically, the worm targeted the gets() function, which lacked bounds checking, enabling attackers to overwrite the return address with shellcode to spawn a command shell via execl("/bin/sh").[3] This vulnerability affected thousands of UNIX systems and contributed to the worm's rapid spread across the early ARPANET.[16] Other early implementation bugs in fingerd included denial-of-service (DoS) conditions from query floods, where repeated or excessive Finger requests could exhaust server resources such as CPU and memory, rendering the service unresponsive.[18] Additionally, redirection exploits, such as infinite query loops triggered by malformed {Q2} options in RFC 1288-compliant implementations, created "finger bombs" that amplified resource consumption and led to service crashes.[18] These issues stemmed from inadequate input validation and lack of rate limiting in early daemons.[19] Following the Morris worm incident, RFC 1288 (published December 1991) introduced security recommendations for Finger implementations, including rigorous penetration testing, filtering of unprintable characters, and protections against malformed inputs to mitigate buffer overflows and similar exploits.[19] Updated daemons in the 1990s incorporated bounds checking in functions like gets() and limited response sizes to prevent overflows and DoS.[20] However, unpatched legacy systems running older BSD or UNIX variants continued to expose these vulnerabilities into the late 1990s and beyond, as many networks retained outdated software without upgrades.[21]Privacy Concerns and Deprecation
The Finger protocol's design allowed for the unrestricted disclosure of personal user information, including real names, email addresses, office locations, and contents of custom .plan files, which could be queried anonymously by anyone over the network. This exposure facilitated social engineering attacks and reconnaissance efforts by adversaries seeking to gather intelligence on individuals or organizations.[22][23] Lacking built-in access controls or authentication mechanisms, the protocol permitted anonymous queries from any remote host, enabling broad dissemination of user data without consent or verification. Such policy-driven openness contravened emerging privacy principles and, in retrospect, conflicted with modern regulations like the General Data Protection Regulation (GDPR), which mandates explicit consent and data minimization for personal information processing.[22][24] Due to these risks and instances of abuse, including exploitation by malware such as the Morris worm, the protocol saw widespread disabling on public Internet hosts by the late 1990s. The IETF, after publishing RFC 1288 in 1991 as a draft standard, issued no further updates or endorsements, effectively rendering it a non-recommended service amid growing security awareness.[22][24][23] In response, network administrators shifted to more secure alternatives like the Lightweight Directory Access Protocol (LDAP), which supports authentication and access restrictions, or web-based directories with user-controlled privacy settings, better aligning with contemporary data protection needs.[24]Implementations and Legacy
Software and System Support
The Finger protocol has seen native support in various Unix-like operating systems, primarily through thefinger command-line client and the fingerd server daemon. In BSD variants, the finger command first appeared in 3.0BSD, providing local and remote user information queries, while the fingerd daemon was introduced in 4.3BSD to handle incoming connections on TCP port 79.[25][26] FreeBSD continues to include both tools natively, with fingerd invoked via inetd or launchd for compatibility with RFC 1288.[27] Linux distributions typically offer the finger client via packages like finger or netkit-finger, which can be installed on Debian-based systems using apt-get install finger and on RPM-based systems using yum install finger.[7][28] The fingerd daemon is available in Linux through packages such as those in the bsdmainutils or standalone implementations, often configured via xinetd.[29] macOS, derived from BSD, included the finger command and fingerd support in versions prior to 10.15 (Catalina), where it was part of the core utilities for user status reporting.[30]
On Windows, early versions provided limited built-in support for the Finger protocol through the finger.exe utility, introduced in Windows NT and carried forward to Windows 2000 and XP, allowing queries to remote UNIX systems running the daemon.[31][32] Later Windows editions, including Windows 10 and Server 2022, retain finger.exe as a TCP/IP command-line tool for compatibility, though it requires an active Finger server on the target host.[31]
Client tools for the Finger protocol are predominantly command-line based, with the finger utility integrated into most Unix shells for querying local users or remote hosts via syntax like finger user@host.[7] Historically, some email clients and terminal emulators incorporated Finger queries to resolve usernames to full names or contact details during composition, enhancing interoperability in early networked environments.[33]
Server-side implementations rely on daemon variants to respond to queries while offering configuration for security. The standard fingerd in FreeBSD supports options like -s for secure mode, which rejects username-less queries and disables forwarding to prevent information leakage.[26] In Linux, fingerd (often from BSD-derived sources) includes flags such as -u to block remote host forwarding and -l for logging requests, configurable in /etc/xinetd.d/finger to limit exposure.[29] Open-source alternatives, including the GNU Finger package's fingerd, provide enhanced features like periodic polling of client hosts for global databases and inetd integration, with build-time options to restrict output fields.[34][35]