Recently, we monitored a cracker from Eastern Europe, who ran 'finger
9@host' against a Solaris 7 box, and got the following result:
Login Name TTY Idle When Where
daemon ??? < . . . . >
bin ??? pts/1 <Oct 2, 2002> xxx.lbl.gov
sys ??? < . . . . >
account1 ??? pts/8 <Jul 20, 2000> yyy.lbl.gov
account2 ??? pts/5 <Dec 17, 1999> zzz.lbl.gov
account3 ??? pts/2 <Jun 30, 2000> aaa.lbl.gov
account4 ??? pts/1 <Feb 17, 2005> bbb.lbl.gov
account5 ??? pts/5 <May 6, 2005> ccc.lbl.gov
account6 ??? pts/9 <Mar 7 15:18> ddd.lbl.gov
This is on a Solaris 7 box with the latest recommended patch set.
This is not the same bug as described here:
Below are snippets of Sun's response:
Sun> The issue you have seen regarding a single digit argument is different
Sun> as this form of ambiguous username returns user information for
Sun> on the system which meet one of the following criteria:
Sun> + an empty GECOS field
Sun> + leading spaces in the GECOS field
Sun> + trailing spaces in the GECOS field
Sun> + a GECOS field with two adjacent spaces
Sun> This latter issue has been addressed in Solaris 10 and later at this
Sun> time under bugID 4432153.
> Thanks for your response. Do you intend to provide patches for older
At this time there aren't any plans to address 4432153 in Solaris 8 or
9. As you may know Solaris 7 is no longer supported. If a service call
was raised with Sun then patches for Solaris 8 and 9 could be generated.
> Under RFC 1288, it seems there should be a mechanism to disable such
> behavior. It certainly is nonintuitive to most folks that 'finger
> 9@host' will display accounts with the GECOS field as described. I
> would also note that other operating systems such as Linux and FreeBSD
> exhibit the behavior that most folks would likely expect:
> $ finger 9@localhost
> finger: 9: no such user
There isn't a way to disable such behaviour as far as we can tell
despite the SHOULD in the RFC. We agree the the behaviour of 'finger
9@host' returning information about accounts with "unusual" whitespace
in the GECOS field is non-intuitive and was also considered incorrect
which is why 4432153 was filed.
Hope this helps.
Does anyone know of other platforms which exhibit this odd behavior?
Incident Response Manager
Computer Protection Program
Lawrence Berkeley National Laboratory