dennis@hpirs.HP.COM (Dennis D. Lee) (04/07/88)
On AT&T System V.2.1 uucp (HoneyDanBer) , the remote system's password is
printed when using the -x option with a level higher than 3.
This is a very serious security hole. Have anybody else noticed this
problem and made a fix to it?
Dennis D. Lee
Hewlett Packard
hpda!hpirs!dennis
jhc@mtunx.ATT.COM (Jonathan Hawbrook-Clark) (04/08/88)
In article <4210002@hpirs.HP.COM> dennis@hpirs.HP.COM (Dennis D. Lee) writes: > On AT&T System V.2.1 uucp (HoneyDanBer) , the remote system's password is > printed when using the -x option with a level higher than 3. I won't swear that this is the case in the version you reference, but at least in later versions such debugging information can be restricted such that it is only printed out when the GID of the invoker passes certain tests. Typically the code is built such that the information is printed when 'root' is running uucico by hand, otherwise a string of question marks is emitted. However, this is a compile-time option, and whoever built the code can set it up any way s/he wants. -- Jonathan Clark jonathan.clark@mtune.att.com, attmail!jonathan Any affiliation is given for identification purposes only. The Englishman never enjoys himself except for some noble purpose.
psfales@iwfap.ATT.COM (fales) (04/08/88)
In article <4210002@hpirs.HP.COM>, dennis@hpirs.HP.COM (Dennis D. Lee) writes: > > On AT&T System V.2.1 uucp (HoneyDanBer) , the remote system's password is > printed when using the -x option with a level higher than 3. > > This is a very serious security hole. Have anybody else noticed this > problem and made a fix to it? This is not a bug, it's a feature! The remote password is only printed when you are running the uucico as root (and -x > 3). This is an aid to administrator's doing debugging, while not compromising security for normal users. -- Peter Fales UUCP: ...ihnp4!ihlpe!psfales work: (312) 979-7784 AT&T Information Systems, IW 1Z-243 1100 E. Warrenville Rd., IL 60566
heiby@mcdchg.UUCP (Ron Heiby) (04/08/88)
Dennis D. Lee (dennis@hpirs.HP.COM) writes: > On AT&T System V.2.1 uucp (HoneyDanBer) , the remote system's password is > printed when using the -x option with a level higher than 3. On the systems I've seen with HoneyDanBer UUCP, there is information compiled into uucico that specifies the range of uids or gids for which the phone number and login information is displayed. I'm uid=501(heiby) gid=101(mot) on my system, and bunches of "?" are displayed instead of sensitive information when I invoke uucico. When I invoke uucico while logged in as "root", I get to see everything. If your implementation does not do this, then it should be fixed by your vendor. -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "I believe in the Tooth Fairy." "I believe in Santa Claus." "I believe in the future of the Space Program."
mikel@codas.att.com (Mikel Manitius) (04/09/88)
In article <116@iwfap.ATT.COM>, psfales@iwfap.ATT.COM (fales) writes: > > This is not a bug, it's a feature! The remote password is only printed > when you are running the uucico as root (and -x > 3). Actually this is configureable at compile time. One can configure the range of group IDs that will have passwords made visible to them at high debug levels. The default is gid 0 to 10, which is why root (gid 0) and uucp (gid 5) get to see them, and normal users don't. -- Mikel Manitius mikel@codas.att.com
honey@umix.cc.umich.edu (Peter Honeyman) (04/10/88)
in svr3, the "sendthem" strings are opaque unless the invoker has read access to the Systems file. peter
friedl@vsi.UUCP (Stephen J. Friedl) (04/11/88)
In article <3976@umix.cc.umich.edu>, honey@umix.cc.umich.edu (Peter Honeyman) writes: > in svr3, the "sendthem" strings are opaque unless the invoker has read > access to the Systems file. ^_________ ucase from peter? is this a first :-) ? > peter It appears that uucico uses the read availability of whichever Systems file is used by the transfer: Systems or Systems.cico (pointed to by Sysfiles). On our machine, one file is readable and the other is not, which drove me crazy with the seemingly random visibility of the sendthem strings. Peter has undoubtedly caused a great many "Aha, so *that's* what is going on." out there. Thanks, Peter. -- Steve Friedl V-Systems, Inc. "Yes, I'm jeff@unh's brother" friedl@vsi.com {backbones}!vsi.com!friedl attmail!vsi!friedl