From jdc@parodius.com  Fri May 25 05:33:50 2001
Return-Path: <jdc@parodius.com>
Received: from parodius.com (pentarou.parodius.com [205.149.163.62])
	by hub.freebsd.org (Postfix) with ESMTP id 160BA37B423
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 25 May 2001 05:33:50 -0700 (PDT)
	(envelope-from jdc@parodius.com)
Received: (from jdc@localhost)
	by parodius.com (8.11.3/8.11.3) id f4PCXnR85086;
	Fri, 25 May 2001 05:33:49 -0700 (PDT)
	(envelope-from jdc)
Message-Id: <200105251233.f4PCXnR85086@parodius.com>
Date: Fri, 25 May 2001 05:33:49 -0700 (PDT)
From: Jeremy Chadwick <jdc@parodius.com>
Reply-To: jdc@parodius.com
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: inetd's internal "auth" service exploits possible bug
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         27636
>Category:       bin
>Synopsis:       inetd's internal "auth" service exploits possible bug
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    dwmalone
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri May 25 05:40:01 PDT 2001
>Closed-Date:    Tue Jul 17 03:45:58 PDT 2001
>Last-Modified:  Tue Jul 17 03:46:28 PDT 2001
>Originator:     Jeremy Chadwick
>Release:        FreeBSD 4.3-STABLE i386
>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:
	inetd's internal "auth" service seems to exploit (or itself
	contain) a bug relating to username lookups.  The entry in
	inetd.conf is:
	auth   stream   tcp   nowait   root   internal   auth -r -t 45

	When a pair of unused ports are provided on port 113 (i.e.
	"1,1" or "0,2"), the daemon returns the error "No such file or
	directory" (taken from strerror()).  I managed to track the
	error down to the sysctlbyname() call within builtins.c.

	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?

	It should be noted that the pidentd daemon in ports/security/pidentd
	does not exhibit this behaviour, yet does the exact same
	sysctlbyname() call.

>How-To-Repeat:
	$ telnet localhost auth
	Trying 127.0.0.1...
	Connected to localhost.
	Escape character is '^]'.
	1,1  
	1 , 1 : ERROR : No such file or directory
	Connection closed by foreign host.
>Fix:
	None that I know of.
>Release-Note:
>Audit-Trail:

From: Peter Pentchev <roam@orbitel.bg>
To: Jeremy Chadwick <jdc@parodius.com>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/27636: inetd's internal "auth" service exploits possible bug
Date: Fri, 25 May 2001 15:49:51 +0300

 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.
 
 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.
 
 G'luck,
 Peter
 
 -- 
 I am jealous of the first word in this sentence.

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 |
 
Responsible-Changed-From-To: freebsd-bugs->dwmalone 
Responsible-Changed-By: dwmalone 
Responsible-Changed-When: Fri May 25 06:38:30 PDT 2001 
Responsible-Changed-Why:  
I'll have a look at this. The real problem seems to be that the builtin 
ident service can return strings not permitted by the RFC. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27636 
State-Changed-From-To: open->closed 
State-Changed-By: dwmalone 
State-Changed-When: Tue Jul 17 03:45:58 PDT 2001 
State-Changed-Why:  
Issue addressed in -current and -stable. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27636 
>Unformatted:
