cfingerd search username vulnerability

Date: Fri, 23 May 1997 22:45:04 -0300
From: Rodrigo Barbosa <rodrigob@MORCEGO.LINKWAY.COM.BR>
To: BUGTRAQ@NETSPACE.ORG
Subject: cfingerd vulnerability

Hello,
        i don't know if it has been noticed before, but cfingerd installs,
by default, a search service. You can use it as:

finger search.username@host

Thats ok, but you can use keymasks. And if you do:

finger search.*@host

you can get a list of all the users in the system.

I've tried it if cfinger 1.2.2 (probably it is not the latest version).

--
Rodrigo Barbosa       (Personal e-mail: rodrigob@darkover.org )
Network Administrator (Work e-mail    : rodrigob@morcego.linkway.com.br )
PGP Key,HomePage address etc: finger rodrigob@morcego.linkway.com.br
PGP Fingerprint: [ D9 15 02 9E 72 32 5A 0A  AC F0 DA 11 6A 4C A3 12 ]
   --> Except where explicitly stated I speak on my own behalf. <--

Date: Sat, 24 May 1997 23:41:24 -0500
From: "Edward S. Marshall" <emarshal@COMMON.NET>
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: cfingerd vulnerability

(This has been cc'd to both Ken Hollis and David Holland, for reasons that
shall become apparent...)

On Fri, 23 May 1997, Rodrigo Barbosa wrote:
> Thats ok, but you can use keymasks. And if you do:
>
> finger search.*@host
>
> you can get a list of all the users in the system.
>
> I've tried it if cfinger 1.2.2 (probably it is not the latest version).

1.3.2 still has the vulnerability, but you need to supply:

finger search.**@host

instead.

This is NotNice(tm). I've CC'd Ken Hollis with this note as well, to make
sure that he's seen it (why do people just mail bugtraq with these things,
instead of emailing authors? Grr...).

Everyone should consider disabling searches if you're running cfingerd.
Ken, would it be possible to have an additional option (if it's not
already in a newer version) to disable any wildcard/regexp matches?

Also, I've heard various reports of cfingerd having security problems in
the past. Has anyone considered sitting down with it and doing a complete
security audit? It's a nice tool to have, but if it's insecure, it
presents a problem. I'm mainly concerned with buffer overruns and other
similar problems, since it does require that you run it as root.

Aw, hell...let me take a stab at Ken's FAQ points on why it has to run as
root, and see if we can't dispel some of these myths:

Point A: cfingerd.conf file should only be readable by root.

Rebuttal: False. It should be read-only by a user that you specify; in
          the case of cfingerd, I'd be more than happy to assign it a
          particular user (say, "finger") to own all of the files.

Point B: In order to change uid/gid to particular users, you must run as
         root.

Rebuttal: True, but what about those of us who don't want users running
          scripts anyway, or are willing to sacrifice that feature for
          security? This should be optional, or you might consider
          employing a modification of the minimal setuid wrapper that
          Apache 1.2 uses to execute CGI scripts for users. This would
          limit the necessity for a setuid binary to a single, tiny,
          auditable program, as opposed to your entire source tree.

Point C: cfingerd may not be able to read .plan or .project files.

Rebuttal: Too bad. Seriously. This is a permissions issue; if the user
          in question doesn't want anything poking into their directory,
          they most certainly should be able to reject intrusions into it.
          As well, most users who make .plan and .project files available
          usually have other files in their home directory that are meant
          for public consumption (when is the last time you considered
          running a web server as root, so that users wouldn't have to
          worry about the permissions on their html directory trees?).

Point D: running as nobody ensures total security

Rebuttal: Ken, come on. This is a falsehood, pure and simple. I won't even
          go into this any further; this is attempting to make the users
          feel better about running as root.

I understand that you've probably been careful with writing cfingerd, Ken,
but running a server like this as root is asking for trouble. You compare
cfingerd and sendmail; there's a reason I switched our systems over to
qmail over sendmail. It's the same reason I'm considering scrapping
cfingerd, and engineering one myself that does what I need.

Plain and simple: cfingerd has no legitimate reason for running as root,
but you have code in place to ensure that I, as the administrator, have no
choice but to do so (the "this daemon must be run as root" problem).

Ken, have you found a new maintainer for cfingerd? If not...then David:
would you be willing to integrate cfingerd into the NetKit package (with
some security auditing)? Might make a nice addition...:-)

--
.-----------------------------------------------------------------------------.
| Edward S. Marshall <emarshal@common.net> | CII Technical Administrator,     |
| http://www.common.net/~emarshal/         | Vice-President, Common Internet  |
| Finger for PGP public key.               | Inc, and Linux & LPmud (ab)user. |
`-----------------------------------------------------------------------------'

Date: Sat, 24 May 1997 22:43:44 -0700
From: Ken Hollis <khollis@POWERBOX.NORTHWEST.COM>
To: BUGTRAQ@NETSPACE.ORG
Subject: Re: cfingerd vulnerability

Edward:

> Everyone should consider disabling searches if you're running cfingerd.
> Ken, would it be possible to have an additional option (if it's not
> already in a newer version) to disable any wildcard/regexp matches?

Right.  The whole idea behind searches was to make it 'compatible' with
GNU Fingerism, but it seemed to have backfired.

> Also, I've heard various reports of cfingerd having security problems in
> the past. Has anyone considered sitting down with it and doing a complete
> security audit? It's a nice tool to have, but if it's insecure, it
> presents a problem. I'm mainly concerned with buffer overruns and other
> similar problems, since it does require that you run it as root.

cfingerd has been shot down many times by previous people, and I have shot
down their arguments, and offered bug reports.  Buffer overruns are
probably still a problem, seeing as I've not upgraded the source to
snprintf.

> Rebuttal: False. It should be read-only by a user that you specify; in
>           the case of cfingerd, I'd be more than happy to assign it a
>           particular user (say, "finger") to own all of the files.

Yawn.  This is the reply of a user that thinks running files as different
users in read-only mode will make any difference at all.  With the
permission set at "root", I am assuring that ONLY root can read the
cfingerd.conf file, since ONLY root should run programs in inetd.

> Rebuttal: True, but what about those of us who don't want users running
>           scripts anyway, or are willing to sacrifice that feature for
>           security? This should be optional, or you might consider
>           employing a modification of the minimal setuid wrapper that
>           Apache 1.2 uses to execute CGI scripts for users. This would
>           limit the necessity for a setuid binary to a single, tiny,
>           auditable program, as opposed to your entire source tree.

Then, disable the script running ability.  Besides, as far as I remember,
you can't allow users to run scripts; the scripts are created and run by
root, in a specific directory.  I believe it was etc/cfingerd ...

> Rebuttal: Too bad. Seriously. This is a permissions issue; if the user
>           in question doesn't want anything poking into their directory,
>           they most certainly should be able to reject intrusions into it.
>           As well, most users who make .plan and .project files available
>           usually have other files in their home directory that are meant
>           for public consumption (when is the last time you considered
>           running a web server as root, so that users wouldn't have to
>           worry about the permissions on their html directory trees?).

Then don't create a .plan or .project file.  You're not forced to do this.

> Rebuttal: Ken, come on. This is a falsehood, pure and simple. I won't even
>           go into this any further; this is attempting to make the users
>           feel better about running as root.

How is running a program as nobody a falsehood?  Are you a programmer?
Have you looked into these types of security when running a program as
setuid?  Obviously you are not, otherwise you would KNOW that running a
program properly set as nobody CANNOT and WILL NOT read files owned by
root unless you screw up your permissions.  But then, that comes down to a
system administration issue.  If you're a good system administrator, this
will not even be an issue.

If they don't like the fact that cfingerd runs as root, then, my answer is
simple:

DON'T RUN CFINGERD.

> I understand that you've probably been careful with writing cfingerd, Ken,
> but running a server like this as root is asking for trouble. You compare
> cfingerd and sendmail; there's a reason I switched our systems over to
> qmail over sendmail. It's the same reason I'm considering scrapping
> cfingerd, and engineering one myself that does what I need.

Oh, okay, so is running telnetd, nfsd, rcpd, rsh, smail, mail, sendmail,
... shall I continue?  Nothing in this world is perfect.  Even qmail's
program runs setuid root and changes uids to the user in question.  I'm
not a stupid coder, I'm not ignorant.  I know what I was doing when I
designed it the way I did.

If you want to scrap cfingerd and write a finger daemon that does the same
things that cfingerd does with no security problems, I welcome to you to
do it.  In fact, I would like to see another.  I've stopped writing
cfingerd and any network protection related programs because of messages
like these.  It's sad that there's people out there that think programs
should be perfect and bug free.  If you think that, go run Microsoft
software.

> Plain and simple: cfingerd has no legitimate reason for running as root,
> but you have code in place to ensure that I, as the administrator, have no
> choice but to do so (the "this daemon must be run as root" problem).

Then don't run cfingerd.  Plain and simple.

> Ken, have you found a new maintainer for cfingerd? If not...then David:
> would you be willing to integrate cfingerd into the NetKit package (with
> some security auditing)? Might make a nice addition...:-)

I've not found a new maintainer for cfingerd.  And since I'm not going to
add any new features to it (ie. I have better things to do with my time
than handle a text parser that 80% of the people out there don't care
about anyway) I've thusly given up on the project, and 1.3.2 is the last
release.

Feel free to work on it.