The cfingerd story
OK, there is no doubt going to be confusion about this so here's the
story.
The original submittor sent in two release-critical bug reports
against cfingerd, one a critical one complaining of buffer overflows
and the other an important one complaining of improper permissions on
scripts.
As it turned out, these were the only remaining release-critical bugs
before hamm's release, and Joey (the maintainer of cfingerd) was
unavailable, so I took a look at the bugs.
I first looked at the important one. He complains that some scripts
are run as root. The example he gave is not a security hole; it is a
script that root writes (like the ip-up script in PPP, for instance.)
He also alluded to improper permissions on user scripts, but did not
tell how to execute them. I was unable to duplicate his problem, and
the code seemed to drop priviledges, so that bug report got closed.
(His explanation for the improper user priviledges was totally
incorrect, leading us to discount the report as well.) I stand by
this action since the problem, AS REPORTED BY HIM, is not there.
The second bug complained of buffer overflows and was reported
critical. An evaluation of the code did reveal numerous buffer
overflows. However, none of them are exploitable. (They are all
dealing with reading root-supplied data -- config files, etc.) So
this bug got downgraded. I stand by this decision as well. (Keep in
mind that the hamm release was very close at that time.) Note that he
refused to tell us what the problems were, just that there were
"overflows" so I had to go over the entire code.
Later on, after the release, he e-mailed me a "secret document" with
the 5 overflows he had found. I again verified that none of these
could lead to a root-compromising hole. The best he can do is crash
cfingerd remotely. But that's no problem anyway since it runs from
inetd. It hurts nobody.
However, his last paragraph in this private message to me mentioned
the script permission issue in a different light than before. It was
still incorrect but it prompted me to go look at cfingerd again. It
does turn out that cfingerd does not properly drop permissions
(although the reason for this is not as he indicated) for some user
scripts if an undocumented exec call is used AND the default
configuration has been modified to something the docs warn may be
insecure. They are run as the user; however, cfingerd neglects to fix
the "real" uid -- so a call to setreuid() in a user-executed program
would gain root access. Also, setgroups() was not called and setgid()
was called at the wrong place. (None of these documented in any way
by the original submittor).
I again looked to see of Joey was around; he wasn't, so I did a NMU on
cfingerd -- the exploit code is three lines long so I figured it would
not be good if we waited, esp. since this has been talked about in
several public places. Subsequently, I sent a post to the usual
places (security, bugtraq).
So to summarize, I believe the actions taken by Joey (Martin Schulze),
Joey Hess (who also downgraded the script permission bug, more or less
simultaneously, for similar reasons), and myself were correct based on
the knowledge we had from the bug submittor (who provided inaccurate
and lacking information about the bugs.) The decision to
downgrade/close those bugs was correct because based on the info in
the bugreport, the bugs never existed or were not release-critical.
I apologize for the confusion -- wanted to let everyone know that we
are still sane. I think. :-)
Thanks,
John Goerzen
--
John Goerzen Linux, Unix consulting & programming jgoerzen@complete.org |
Developer, Debian GNU/Linux (Free powerful OS upgrade) www.debian.org |
----------------------------------------------------------------------------+
Visit the Air Capital Linux Users Group on the web at http://www.aclug.org
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: