Finger ( Finger )

• Flow of events

Finger is based on the Transmission Control Protocol, using TCP port 79 decimal (117 octal). A TCP connection is opened to a remote host on the Finger port. An RUIP becomes available on the remote end of the connection to process the request. The RUIP is sent a one line query based upon the Finger query specification. The RUIP processes the query, returns an answer, then closes the connection normally.


• 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.


• Query specifications

An RUIP MUST accept the entire Finger query specification. The Finger query specification is defined:


{Q1}	::= [{U}] [/W] {C}
{Q2}	::= [{U}]{H} [/W] {C}
{U}	::= username
{H}	::= @hostname | @hostname{H}
{C}	::=



{H}, being recursive, 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 line that an RUIP actually receives. So, if a user types "finger user@host", the RUIP on the remote host receives "user", which corresponds to {Q1}.

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



• RUIP {Q2} behavior

A query of {Q2} is a request to forward a query to another RUIP. An RUIP MUST either provide or actively refuse this forwarding service. If an RUIP provides this service, it MUST conform to the following behavior:

Given that:
Host H1 opens a Finger connection F1-2 to an RUIP on host H2.

H1 gives the H2 RUIP a query Q1-2 of type {Q2} (e.g., FOO@HOST1@HOST2).


• Expected RUIP response

For the most part, the output of an RUIP 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 discussion in the security section.

• {Q2} refusal

For individual site security concerns, the system administrator SHOULD be given an option to individually turn on or off RUIP processing of {Q2}. If RUIP processing of {Q2} is turned off, the RUIP MUST return a service refusal message of some sort. "Finger forwarding service denied" is adequate. The purpose of this is to allow individual hosts to choose to not forward Finger requests, but if they do choose to, to do so consistently.


• {C} refusal

For individual site security concerns, the system administrator SHOULD be given an option to individually turn on or off RUIP acceptance of {C}. If RUIP processing of {C} is turned off, the RUIP MUST return a service refusal message of some sort. "Finger online user list denied" is adequate. The purpose of this is to allow individual hosts to choose to not list the users currently online.


• Atomic discharge

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


• 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.


• Audit trails

Implementations SHOULD allow system administrators to log Finger queries.

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

• BSD Unix

Finger appeared in version 3.0 of the Berkeley Software Distribution (BSD) Unix. According to the system documentation the Finger command usually "displays the user's login name, real name, terminal name and write status (as a ``*'' before the terminal name if write permission is denied), idle time, login time, office location and office phone number." By using the ¨Cl option, the following information would be displayed: "the user's home directory, home phone number, login shell, and the contents of the files ".forward'', ".plan'" and ".project'' from the user's home directory."


• Solaris Unix

In Sun's Solaris the default for the Finger command is to display the following information: user name, user's full name, terminal name (prepended with a `*' (asterisk) if write-permission is denied), idle time, login time, and host name if logged in remotely. If queried for a specific user than the following is provided: the user name and the user's full name, the user's home directory and login shell, time the user logged in if currently logged in, or the time the user last logged in; and the terminal or host from which the user logged in, last time the user received mail, and the last time the user read mail, the first line of the $HOME/.project file, if it exists, the contents of the $HOME/.plan file, if it exists


• GNU Finger

The Finger command was designed to provide information about users on a computer system. This worked well in the 1970s when there were many people connected to one computer. However, by the 1990s, the networking environment had changed. In the 1990s there were many computers mostly with a single user. To Finger someone in the 1990s, it was necessary to Finger each individual computer. The GNU Finger implementation solved this problem by creating a central database listing all of the users in the site. This database was derived by continuously querying all the different computers at a "site". GNU Finger was developed in October 1992 and replaced Berkeley 4.3 Finger code.


• PFinger

Another implementation of Finger, it is more recent. It claims that it has several security advantages over conventional implementations of the Finger command. For example, it allows .pgpfiles, no printing of users shell, home directory, and last login time. It also allows users to turn off Finger information by creating a .noFinger file or a user can update and store their own information.


• Configurable Finger Daemon (CFingerd)

CFingerd is considered a hacked Finger daemon which provides extra security functions. It is considered an excellent replacement for standard Finger daemons. (1998) It was written by Ken Hollis with security issues in mind. According to its creators, cFingerd was created because many sites were turning off Finger for outside users. The system administrators did not want outsiders obtaining information about the users on the system. This program was created to provide these sites with a secure alternative.


• FFingerD

FFingerd was created as secure Finger service in response to system administrators disabling the Finger service because Finger advertised too much information about the system and the security flaws in standard Finger daemons. Some key features: "It has been verified to compile on a wide variety of Unix variants. It does not run with superuser privileges. It can display PGP public keys, too. It even has a fascist logging option for paranoid administrators. Users can exclude their account from Fingering. You can't see if an account has been excluded or is not there."


• Troll-Ftpd

Alternative to wu-ftpd and BSD Finger daemon which have security flaws. It is designed for Linux.


• PsFingerD

In response to standard Finger daemon's that provide home directory, shell, and last login information which is valuably to hackers, PsFingerd was created. Some of the features of psFingerd are Disallowing indirect Fingers and empty Fingers, Support for pgp public key, .noFinger option, and the ability for users to hide their real name.

Example 1: Example with a null command line ({C})



Site: elbereth.rutgers.edu

Command line:CRLF

Login
Name
TTY Idle
When
Office
rinehart
Mark J. Rinehart
p0
1:11 Mon 12:15
019 Hill x3166
greenfie
Stephen J. Greenfiel
p1
Mon 15:46
542 Hill x3074
rapatel
Rocky - Rakesh Patel
p3
4d Thu 00:58
028 Hill x2287
pleasant
Mel Pleasant
p4
3d Thu 21:32
019 Hill 908-932
dphillip
Dave Phillips
p5
021: Sun 18:24
265 Hill x3792
dmk
David Katinsky
p6
2d Thu 14:11
028 Hill x2492
cherniss
Cary Cherniss
p7
5 Mon 15:42
127 Psychol x2008
harnaga
Doug Harnaga
p8
2:01 Mon 10:15
055 Hill x2351
brisco
Thomas P. Brisco
pe
2:09 Mon 13:37
h055 x2351
laidlaw
Angus Laidlaw
q0
1:55 Mon 11:26
E313C 648-5592
cje
Chris Jarocha-Ernst
q1
8 Mon 13:43
259 Hill x2413

Example 2: Example with name specified ({U}{C})



          Site: dimacs.rutgers.edu

          Command line: pirmann

          Login name: pirmann                        In real life: David Pirmann

          Office: 016 Hill, x2443                      Home phone: 989-8482

          Directory: /dimacs/u1/pirmann           Shell: /bin/tcsh

          Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers.

          No unread mail

          Project:

          Plan:

                           Work Schedule, Summer 1990

                      Rutgers LCSR Operations, 908-932-2443



                             Monday       5pm - 12am

                             Tuesday      5pm - 12am

                             Wednesday    9am -  5pm

                             Thursday     9am -  5pm

                             Saturday     9am -  5pm



                                larf larf hoo hoo

Example 3: Example with ambiguous name specified ({U}{C})



          Site: elbereth.rutgers.edu

          Command line: ron

          Login name: spinner                     In real life: Ron Spinner

          Office: Ops Cubby,    x2443             Home phone: 463-7358

          Directory: /u1/spinner                  Shell: /bin/tcsh

          Last login Mon May  7 16:38 on ttyq7

          Plan:



                                ught i

                              ca      n

                            m           a

                          '      ...     t

                          I      .   .     i

                                 !         m  

                          !       !       e

                           p       !pool

                            l

                             e

                              H



          Login name: surak                       In real life: Ron Surak

          Office: 000 OMB Dou,    x9256

          Directory: /u2/surak                    Shell: /bin/tcsh

          Last login Fri Jul 27 09:55 on ttyq3

          No Plan.



          Login name: etter                       In real life: Ron Etter

          Directory: /u2/etter                    Shell: /bin/tcsh

          Never logged in.

          No Plan.

Example 4: Example of query type {Q2} ({U}{H}{H}{C})



          Site: dimacs.rutgers.edu

          Command line: hedrick@math.rutgers.edu@pilot.njin.net



          [pilot.njin.net]

          [math.rutgers.edu]

          Login name: hedrick                     In real life: Charles Hedrick

          Office: 484 Hill, x3088

          Directory: /math/u2/hedrick             Shell: /bin/tcsh

          Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge

          No unread mail

          No Plan.

■ Parent layer
■ Child layer

TCP

Finger