Edward S. Marshall (emarshal@COMMON.NET)
Sat, 24 May 1997 23:41:24 -0500
(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. | `-----------------------------------------------------------------------------'
This archive was generated by hypermail 2.0b3 on Sun Aug 08 1999 - 10:48:01 CEST