Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!jarthur!ucivax!gateway From: david@twg.COM ("David S. Herron") Newsgroups: comp.protocols.iso.x400.gateway Subject: Re: UUXQT Problems with X.400 encoded O/R Names Message-ID: <8701@gollum.twg.com> Date: 1 Mar 91 01:49:42 GMT References: <9102250732.AA15991@earth.touch.com> Organization: The Wollongong Group, Palo Alto, CA Lines: 73 Approved: usenet@ICS.UCI.EDU x-attn: jns X-Previously-To: comp-protocols-iso-x400-gateway@cis.ohio-state.edu ReSent-From: Jerry Sweet ReSent-To: ifip-gtwy@ICS.UCI.EDU In article <9102250732.AA15991@earth.touch.com> kehres@touch.COM (Tim Kehres) writes: ... >The problems were in reference to the UNIX HDB UUCP utility, UUXQT >consulting the Permissions file and determining that the supplied address >represented a file name (the leading '/'), and then refusing the >transaction based upon improper access to this file name. For example, >the following address would cause this problem: > > /c=us/admd=sprint/prmd=touch/s=kehres/@somewhere.com > >Has anyone had any further experience with this problem? As we left it, >the only workaround we found was to totally relax the permissions to allow >reading and writing from the root directory (not a very nice solution). This "problem" exists for ALL implementations of UUCP. At least, for all the ones I've seen (since V7), I am under the impression that versions before some particular event did not have much/any security and my guess that the CAPITAL LETTERS about SECURITY HOLES if you open up world access have something to do with this event. That aside .. The security arrangement in uucp/uucico/uuxqt (this is Unix, we don't use CAPITALS unless as want emphasis ;-) ) look for file names and check that the remote site is allowed access to those file names. For `uuxqt' it looks on the command line for file names and blindly assumes that anything there is potentially a file which can be accessed and sent somewhere. Since uucp mail is initiated by uux - remote!rmail host!host!host!local-part ... or uux - remote!rmail local-part@domain-part ... The forward-addresses are subject to scrutinizing by these security features. Since X.400/X.500 ORNames have an unfortunate resemblance to Unix file names uuxqt (the daemon which handles uux requests) will scream bloody murder and not do anything. There is an obvious workaround -- don't put forward addresses on the command line. If you look through the comp.sources.{misc,unix} archive you'll find a program I did long-long ago in a job far-far away which implements a variety of this workaround. >I have heard unconfirmed rumors that AT&T's response has been that they >had no intention to do anything about this except in cases where it could >effect AT&T Mail. From a security standpoint it makes NO SENSE for AT&T to "fix" this because it simply ain't broke. It's up to us software wizards to do UUCP mail right. >This is a significant problem since it effects *all* sites running HDB >UUCP, regardless of the vendor (Interactive, SCO, and HP as well as many >other implementations are all effected). Again, it also affects sites running V2 UUCP (BSD derived machines tend to have this, except that (at least) SunOS has HDB nowadays). Note: It may be tempting for OSI/X.400 purists to think that UUCP and its ilk will eventually disappear. UUCP is very good at data transfers between intermittently connected sites. David -- <- David Herron, an MMDF & WIN/MHS guy, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- MS-DOS ... The ultimate computer virus.