🚀 go-pugleaf

In <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).

>Any insight regarding other workarounds, or fixes would be greatly
>appreciated.


We were also struck by this problem. But it was solved on our site simply
by eliminating recipients addresses from the uux arguments - we use
not
	uux somewhere!rmail

but
	uux somewhere!foobar

And foobar accepts recipients addresses inside data files.

>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).

Yes, and our workaround doesn't save us from rejecting the mail
from somewhere en route to sprint.com.

BTW, I called SCO, and they've put this bug in their bug database.
But they haven't made any fixes (at least I haven't heard about it),
just advised to relax Permissions security - and we couldn't accept it.

--
Dmitry V. Volodin <dvv@hq.demos.su>      |
fax:    +7 095 233 5016                  |      Call me Dima ('Dee-...)
phone:  +7 095 231 2129			 |

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, <david@twg.com>
<- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu>
<-
<-	MS-DOS ... The ultimate computer virus.