[18714] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Solaris /usr/bin/cu Vulnerability

daemon@ATHENA.MIT.EDU (Michael H. Warfield)
Fri Jan 19 12:49:58 2001

Mail-Followup-To: Konrad Rieck <kr@r0q.cx>, BUGTRAQ@SECURITYFOCUS.COM
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <20010119105045.E21841@alcove.wittsend.com>
Date:         Fri, 19 Jan 2001 10:50:45 -0500
Reply-To: "Michael H. Warfield" <mhw@WITTSEND.COM>
From: "Michael H. Warfield" <mhw@WITTSEND.COM>
X-To:         Konrad Rieck <kr@r0q.cx>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <20010118235712.A1502@inf.fu-berlin.de>; from kr@R0Q.CX on Thu,
              Jan 18, 2001 at 11:57:12PM +0100

On Thu, Jan 18, 2001 at 11:57:12PM +0100, Konrad Rieck wrote:
> > (Dont know about Solaris 8)

> I could reproduce the segmentation fault on Solaris 8 x86 and Sparc.
> The source of /usr/bin/cu shows that argv[0] is simply strcpy()'ed to
> a buffer that is only 15 bytes long. Using strncpy() might be a
> solution.

> The strange thing is that all other programs that are part of the uucp
> package copy a constant program name into the buffer and don't use
> argv[0] at all. (bnuconvert, ct, dial, uucheck, uucico, uucleanup, uucp,
> uushched, uustat, uux and uuxqt).

> Well, maybe people at Sun can explain, why it is necessary to retrieve
> the program name from the arguments in case of cu. I am a total uucp
> fool and have no clue.

	Oh that one's easy for some of us old farts familiar with the
old uucp days (I still have a couple of live links)...

	Cu from both HDB (most commercial Unix) and, I believe AT&T BNU
(ancient pre SVr3.2) had a provision where it could be linked to a
system name.  Executing "foo" would then act the same as the command
"cu foo".  You could then keep a directory of them like /usr/cu/{systems}.

	That also explains the size of that buffer...  That was the
maximum length allowed for a uucp system name.

	Taylor UUCP (Freeware / Opensource) doesn't appear to have that
facility at all.  Since that was a documented "feature" of cu in the
olden days, maybe the lack of that feature is a bug in Taylor uucp.  :-)
I don't hear anyone complaining...  :->

	If it's present in the Solaris cu, I would be very much
surprised if it wasn't in the majority of HDB uucp cu implimentations.
It's not present in Taylor uucp cu.

> cu is only set setuid for the owner uucp and an attacker won't gain any
> special privileges, but he would gain access to the files in /etc/uucp.

	Correction...  He does gain special privileges.  He gains access
to all the uucp control files which can contain account names and passwords
on other systems.  It ain't root, but it's more than what he should have.

> Regards,
> Konrad

> --
> Konrad Rieck <kr@r0q.cx>
> Roqefellaz - http://www.r0q.cx, GPG Public Key http://www.r0q.cx/keys/kr.pub
> --           Fingerprint: 3AA8 CF92 C179 9760 C3B3  1B43 33B6 9221 AFBF 5897

	Mike
--
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

home help back first fref pref prev next nref lref last post