The Finger User Information Protocol
obsoletes
Extracted elements (27)
It is RECOMMENDED that the default for {Q2} processing be to refuse, because cases warranting forwarding are far outweighed by cases for refusing. A machine at a security perimeter that enables {Q2} provides a path through that perimeter, making the default-deny posture critical for gateway machines.
The output of an RUIP does not follow a strict specification because it is designed to be read by people rather than programs; it should mainly strive to be informative. This contrasts with machine-parseable protocol responses.
The protocol is based primarily on the BSD UNIX Finger implementation from UC Berkeley, which provides the de facto behavioral baseline. However, BSD Finger provides few options for tailoring security policy or protecting users from dangerous data, motivating the security recommendations in this memo.
RFC 1288 corrects RFC 1196: the /W token is placed at the beginning of the query line (matching 4.3BSD Finger behavior), not at the end as RFC 1196 mistakenly specified. The BNF was also clarified to explicitly represent blank space.
A {C} (null command line) query is a request for a list of all online users. An RUIP MUST either answer or actively refuse. If it answers, it MUST provide at least the user's full name.
A {U}{C} query response MUST include at least the full name of the specified user. If the user is logged in, at least the same amount of information returned by a {C} query for that user MUST also be returned.
All Finger implementations SHOULD allow individual system administrators to tailor which atoms of information (e.g., office location, phone number, home phone, login/logout time) are returned in response to a query, down to the minimum of the person's full name.
Allowable names in the {U} component of a query MUST include 'user names' or 'login names' as defined by the system. The system administrator SHOULD be allowed to choose whether ambiguous name lookups return all possible matching users.
An RUIP MUST accept the entire Finger query specification, including both {Q1} and {Q2} query forms. The liberal-acceptance principle applies: 'be liberal in what you accept'.
An RUIP MUST either provide or actively refuse the {Q2} forwarding service. If it provides the service, it MUST open a connection to the rightmost host in the query, forward the remainder of the query, relay the response back, and close only when the remote RUIP closes.
Any data transferred MUST be in ASCII format, with no parity, and with lines ending in CRLF (ASCII 13 followed by ASCII 10). Characters between ASCII 128 and 255 should truly be international data, not 7-bit ASCII with the parity bit set.
By default, client programs SHOULD filter any unprintable data from RUIP responses, retaining only printable 7-bit characters (ASCII 32–126), tabs (ASCII 9), and CRLFs, to protect against terminal escape code attacks and window-name hijacking.
Implementations SHOULD allow system administrators to log Finger queries for audit trail purposes.
The system administrator SHOULD be given an option to individually turn on or off RUIP acceptance of {C} (online user list) queries. If {C} processing is turned off, the RUIP MUST return a service refusal message such as 'Finger online user list denied'.
Two separate user options SHOULD be provided in client programs to allow viewing non-default characters: one to allow characters below ASCII 32, and another to allow characters above ASCII 126, to support international data.
A {Q2} query requests forwarding to another RUIP. The {H} token in the query is recursive, allowing chained forwarding through multiple hosts with no arbitrary limit on the number of @hostname tokens.
A user information file ('plan' file) is a user-modifiable file whose contents are included in the response to {U}{C} Finger queries. The system administrator SHOULD be allowed to specifically turn this feature on and off.
An RUIP MAY allow a user to run a program in response to a Finger query. If this feature exists, the system administrator SHOULD be allowed to specifically enable or disable it; the RUIP MUST NOT allow system security to be compromised by that program.
Finger uses TCP port 79. The local host opens a TCP connection to the remote host on the Finger port, sends a one-line query, waits for the RUIP (Remote User Information Program) to respond, and the RUIP initiates the close of the connection after returning an answer.
The /W token in a {Q1} or {Q2} query SHOULD be interpreted at the last RUIP to signify a higher level of verbosity in user information output, or at worst be ignored. Its placement is at the beginning of the query line.
A malicious user's persistent use of {U} ambiguity can result in enumerating most usernames on a system. Refusal of {U} ambiguity should be considered in the same vein as refusal of {C} requests.
Allowing an RUIP to execute user programs in response to Finger queries is potentially dangerous. The RUIP MUST NOT allow system security to be compromised by such programs. Operating system bugs can be exploited via this mechanism.
Allowing an RUIP to return information from a user-modifiable file is equivalent to allowing any information about the system to be freely distributed. This can enable information disclosure in clever or straightforward ways and should disturb administrators who wish to control returned data.
Finger discloses potentially sensitive information about users, including login times, mail status, and correspondents. Security administrators should make explicit decisions about whether to run Finger and what information to provide; sites that are information-security conscious should not run Finger without understanding how much information it reveals.
Finger implementations SHOULD be tested against various forms of attack, and an RUIP SHOULD protect itself against malformed inputs. Finger was one avenue exploited by the Morris worm and sits at the security perimeter of a host alongside Telnet, FTP, and SMTP.
Finger connection flow: (1) local host opens TCP connection to port 79 on remote host; (2) RUIP processes the one-line query; (3) RUIP returns answer then initiates TCP close; (4) local host receives answer and close signal, then closes its end. The RUIP initiates close, not the client.
The Finger query is a single line conforming to {Q1} ::= [{W}|{W}{S}{U}]{C} for direct queries, or {Q2} ::= [{W}{S}][{U}]{H}{C} for forwarded queries, where {U} is a username, {H} is @hostname (recursive), {W} is /W, {S} is one or more spaces, and {C} is CRLF.