Bugtraq mailing list archives
Re: Solaris /usr/bin/cu Vulnerability
From: "Michael H. Warfield" <mhw () WITTSEND COM>
Date: Fri, 19 Jan 2001 10:50:45 -0500
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!
Current thread:
- Solaris /usr/bin/cu Vulnerability Pablo Sor (Jan 18)
- Re: Solaris /usr/bin/cu Vulnerability Tomas Cibulka (Jan 18)
- Re: Solaris /usr/bin/cu Vulnerability Juergen P. Meier (Jan 19)
- Re: Solaris /usr/bin/cu Vulnerability Casper Dik (Jan 22)
- Re: Solaris /usr/bin/cu Vulnerability Juergen P. Meier (Jan 19)
- Solaris /usr/bin/cu Vulnerability hal King (Jan 23)
- Re: Solaris /usr/bin/cu Vulnerability Dan Harkless (Jan 30)
- <Possible follow-ups>
- Re: Solaris /usr/bin/cu Vulnerability Konrad Rieck (Jan 19)
- Re: Solaris /usr/bin/cu Vulnerability Michael H. Warfield (Jan 19)
- Re: Solaris /usr/bin/cu Vulnerability Wietse Venema (Jan 22)
- Re: Solaris /usr/bin/cu Vulnerability Michael H. Warfield (Jan 19)
- Re: Solaris /usr/bin/cu Vulnerability optyx (Jan 30)
- Re: Solaris /usr/bin/cu Vulnerability Dan Harkless (Jan 31)
- Re: Solaris /usr/bin/cu Vulnerability Tomas Cibulka (Jan 18)