Date: Fri, 25 May 2001 06:10:03 -0700 (PDT) From: Jeremy Chadwick <jdc@parodius.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/27636: inetd's internal "auth" service exploits possible bug Message-ID: <200105251310.f4PDA3s19648@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/27636; it has been noted by GNATS.
From: Jeremy Chadwick <jdc@parodius.com>
To: Peter Pentchev <roam@orbitel.bg>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/27636: inetd's internal "auth" service exploits possible bug
Date: Fri, 25 May 2001 06:06:37 -0700
On Fri, May 25, 2001 at 03:49:51PM +0300, roam@orbitel.bg wrote:
> On Fri, May 25, 2001 at 05:33:49AM -0700, Jeremy Chadwick wrote:
> >
> > >Number: 27636
> > >Category: bin
> > >Synopsis: inetd's internal "auth" service exploits possible bug
> > >Originator: Jeremy Chadwick
> > >Organization:
> > Parodius Networking
> > >Environment:
> > System: FreeBSD pentarou.parodius.com 4.3-STABLE FreeBSD 4.3-STABLE #0: Sat May 19 19:55:39 PDT 2001 root@pentarou.parodius.com:/usr/obj/usr/src/sys/PARODIUS-SMP i386
> >
> >
> > >Description:
> >
> [snip]
> > sysctlbyname(), in this case, returns -1 and sets errno to
> > ENOENT. sysctlbyname() is being called against a "mysterious"
> > sysctl variable, "net.inet.tcp.getcred." I use the word "mysterious"
> > because the entry is 1. undocumented, 2. returns ENOENT, and 3.
> > ENOENT is not listed in the sysctlbyname(3) manpage as a valid
> > error code (but the kernel **DOES** return ENOENT!).
> >
> > Could someone please 1. fix this issue, 2. explain why ENOENT
> > was chosen as a return value for the kernel (when it doesn't
> > seem to be interacting with any files in this case), and 3. fix
> > the manpage so that it contains proper updated information?
>
> Just as a random thought: I'd guess that the inappropriate wording is
> not in choosing ENOENT, but in the (all too common) representation
> of this error as 'no such file or directory'. From the name, it would
> seem that ENOENT was meant as a generic 'no such entity' return code
> to be used for all types of objects, not just files or directories.
> The error message was crafted that way because in the overwhelming
> majority of cases, an ENOENT error refers to a file-type object.
True; I'm hearing you on FM. However, there's a whole slew
of available error codes for reporting something much more
proper, in errno.h. Something gives me the impression (and I
could be flat-out wrong with this assumption) that the author
of the kernel code chose ENOENT because it was quick-and-dirty.
As I don't have any idea what the kernel code actually *does*, I
suppose I'm out on a limb.
> In this particular case, I believe ENOENT is the appropriate error code
> for a non-existing sysctl name (and why not for MIB's, too?), and IMHO,
> the documentation (and kernel sysctl code) should be changed to refer
> to ENOENT, and not the currently used EOPNOTSUPP, for both names and
> MIB's.
There's multiple issues to this bug report, as you can tell.
Half of them relate to inetd, the other half relate to the
sysctlbyname() issue and it's (lack-of) documentation. I
wasn't sure if send-pr permitted multiple categories, other-
wise I would have picked "bin,kern."
Here's the best part: the sysctl variable *DOES* indeed exist.
Herein lies the magic:
[5:53/pentarou] ~$ su2
Password:
[5:53/pentarou] /home/jdc$ sysctl net.inet.tcp.foobar
sysctl: unknown oid 'net.inet.tcp.foobar'
[5:53/pentarou] /home/jdc$ sysctl net.inet.tcp.getcred
[5:53/pentarou] /home/jdc$ sysctl net.inet.udp.getcred
[5:53/pentarou] /home/jdc$
I find this very peculiar. I am lead to believe that basically
the results of a sysctlbyname(3) call on the entry for
net.inet.[tcp|udp].getcred are supposed to contain the UID of
the owner of the socket. I'm not quite sure *WHY* sysctl was
chosen for this, but I digress...
It's possible that inetd is not properly passing the correct
socket structures to sysctlbyname(), or that they're not
being filled correctly prior to the call itself. I'm lead
to believe this solely because of the kernel code I looked
at. It's also possible that error code 2 is the return code
for "No credentials for that socket." I really don't know, as
the entire sysctl variable itself seems special. I'm totally
unsure either way; I just know pidentd does the same call and
does not have this problem.
I believe inetd should be returning "NO-USER" in this case.
"No such file or directory" is *very* misleading, as I'm sure
all of us will agree; the error implies a worse problem, and
could cause system administrators to go on a wild goose chase
searching for nothing. Not to mention, who knows what outsiders
think ("No such file or directory? Niiice...").
Just food for thought. *crossing fingers on a fix* :-)
--
| Jeremy Chadwick jdc@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105251310.f4PDA3s19648>