IdFinger

The TIdFinger is a TIdTCPClientCustom descendant that implements a TCP-based variant of the Finger User Information Protocol or Finger client, as described in the Internet Standards document: 

RFC 1288 - The Finger User Information Protocol  

Overview of the Finger Protocol 

The Finger protocol is an interface for a database of information about users on a remote system. The Finger protocol can include information such as if a user is logged in to the system, when the user last read their E-Mail, or optional information the user wishes to make available publicly (.plan file). 

Finger is based on the Transmission Control Protocol, using TCP port 79 decimal (117 octal). The local host opens a TCP connection to a remote host on the Finger port. The local host sends a one line query based upon the Finger query specification, and waits for the responce. 

The Finger server 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 closing its end of the connection. 

Data format 

Any data transferred MUST be in ASCII format, with no parity, and with lines ending in CRLF (ASCII 13 followed by ASCII 10). This excludes other character formats such as EBCDIC, etc. This also means that any characters between ASCII 128 and ASCII 255 should truly be international data, not 7-bit ASCII with the parity bit set. 

Finger Query Specifications 

The Finger query specification is defined using the following tokens and productions: 

   {Q1}    ::=  [{W}|{W}{S}{U}]{C}

   {Q2}    ::=  [{W}{S}][{U}]{H}{C}

   {U}     ::=  username

   {H}     ::=  @hostname | @hostname{H}

   {W}     ::=  /W

   {S}     ::=  <SP> | <SP>{S}

   {C}     ::=  <CRLF>

{H} is recursive, and means that there is no arbitrary limit on the number of @hostname tokens in the query. In examples of the {Q2} request specification, the number of @hostname tokens is limited to two, simply for brevity. 

Be aware that {Q1} and {Q2} do not refer to a user typing "finger user@host" from an operating system prompt. It refers to the data actually received by the handler for the finger request on the remote server. So, if a user types "finger user@host<CRLF>", the RUIP on the remote host receives "user<CRLF>", which corresponds to {Q1}. 

As with anything in the IP protocol suite, "be liberal in what you accept". 

Expected Finger Responses 

For the most part, the output of a Finger query doesn't follow a strict specification, since it is designed to be read by people instead of programs. It should mainly strive to be informative. 

Output of ANY query is subject to the security restrictions that apply the connection to the Finger server. 

{C} Query 

A query of {C} is a request for a list of all online users. The remote server must either answer or actively refuse the query. If it answers, then it MUST provide at least the user's full name. The system administrator SHOULD be allowed to include other useful information, such as: 

• terminal location
• office location
• office phone number
• job name
• idle time (number of minutes since last typed input, or since last job activity).

{U}{C} Query 

A query of {U}{C} is a request for in-depth status of a specified user {U}. If you really want to refuse this service, you probably don't want to be running Finger in the first place. 

An answer MUST include at least the full name of the user. If the user is logged in, at least the same amount of information returned by {C} for that user MUST also be returned by {U}{C}. 

Since this is a query for information on a specific user, the system administrator SHOULD be allowed to choose to return additional useful information, such as: 

• office location
• office phone number
• home phone number
• status of login (not logged in, logout time, etc)
• user information file

A user information file is a feature wherein a user may leave a short message that will be included in the response to Finger requests. (This is sometimes called a "plan" file.) This is easily implemented by (for example) having the program look for a specially named text file in the user's home directory or some common area; the exact method is left to the implementor. The system administrator SHOULD be allowed to specifically turn this feature on and off. 

There MAY be a way for the user to run a program in response to a Finger query. If this feature exists, the system administrator SHOULD be allowed to specifically turn it on and off. 

{U} Ambiguity 

Allowable "names" in the command line MUST include "user names" or "login names" as defined by the system. If a name is ambiguous, the system administrator SHOULD be allowed to choose whether or not all possible derivations should be returned in some fashion. 

/W query token 

The token /W in the {Q1} or {Q2} query types SHOULD at best be interpreted at the last RUIP to signify a higher level of verbosity in the user information output, or at worst be ignored. 

Vending machines 

Vending machines SHOULD respond to a {C} request with a list of all items currently available for purchase and possible consumption. Vending machines SHOULD respond to a {U}{C} request with a detailed count or list of the particular product or product slot. Vending machines should NEVER NEVER EVER eat money. 

Implementation Security 

Sound implementation of Finger is of the utmost importance. Implementations should be tested against various forms of attack. In particular, an server SHOULD protect itself against malformed inputs. Vendors providing Finger with the operating system or network software should subject their implementations to penetration testing. 

Finger is one of the avenues for direct penetration, as the Morris worm pointed out quite vividly. Like Telnet, FTP and SMTP, Finger is one of the protocols at the security perimeter of a host. Accordingly, the soundness of the implementation is paramount. The implementation should receive just as much security scrutiny during design, implementation, and testing as Telnet, FTP, or SMTP. 

RUIP security 

Warning!! Finger discloses information about users; moreover, such information may be considered sensitive. Security administrators should make explicit decisions about whether to run Finger and what information should be provided in responses. One existing implementation provides the time the user last logged in, the time he last read mail, whether unread mail was waiting for him, and who the most recent unread mail was from! This makes it possible to track conversations in progress and see where someone's attention was focused. Sites that are information-security conscious should not run Finger without an explicit understanding of how much information it is giving away. 

Atomic Discharge 

All implementations of Finger SHOULD allow individual system administrators to tailor what atoms of information are returned to a query. For example: 

• Administrator A should be allowed to specifically choose to return office location, office phone number, home phone number, and logged in/logout time.

• Administrator B should be allowed to specifically choose to return only office location, and office phone number.

• Administrator C should be allowed to specifically choose to return the minimum amount of required information, which is the person's full name.

User Information Files 

Allowing an RUIP to return information out of a user-modifiable file should be seen as equivalent to allowing any information about your system to be freely distributed. That is, it is potentially the same as turning on all specifiable options. This information security breach can be done in a number of ways, some cleverly, others straightforwardly. This should disturb the sleep of system administrators who wish to control the returned information. 

Execution of User Programs 

Allowing an RUIP to run a user program in response to a Finger query is potentially dangerous. BE CAREFUL!! -- the RUIP MUST NOT allow system security to be compromised by that program. Implementing this feature may be more trouble than it is worth, since there are always bugs in operating systems, which could be exploited via this type of mechanism. 

{U} ambiguity 

Be aware that a malicious user's clever and/or persistent use of this feature can result in a list of most of the usernames on a system. Refusal of {U} ambiguity should be considered in the same vein as refusal of {C} requests. 

Audit trails 

Implementations SHOULD allow system administrators to log Finger queries. 

Client security 

It is expected that there will normally be some client program that the user runs to query the initial RUIP. By default, this program SHOULD filter any unprintable data, leaving only printable 7-bit characters (ASCII 32 through ASCII 126), tabs (ASCII 9), and CRLFs. 

This is to protect against people playing with terminal escape codes, changing other peoples' X window names, or committing other dastardly or confusing deeds. Two separate user options SHOULD be considered to modify this behavior, so that users may choose to view international or control characters: 

• one to allow all characters less than ASCII 32
• another to allow all characters greater than ASCII 126

For environments that live and breathe international data, the system administrator SHOULD be given a mechanism to enable the latter option by default for all users on a particular system. This can be done via a global environment variable or similar mechanism.

IndySupport