kehres@touch.COM (Tim Kehres) (02/26/91)
A few months ago there was some discussion regarding the problems with the sending of X.400 O/R Names through a System V UUCP channel. Most of these discussions I am assuming were in somewhat private circles, and as far as I can tell, nothing has come of them. 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). 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. Has anyone heard anything else regarding this, either to confirm this, or to prove it false? Please don't misinterpret me here, I am not out to get AT&T, in fact I am hoping AT&T might be able to prove the rumors wrong and provide an industry wide fix to this problem. 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). Any insight regarding other workarounds, or fixes would be greatly appreciated. Best Regards, Tim Kehres
dvv@hq.demos.su ("Dmitry V. Volodin") (02/28/91)
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 |
david@twg.COM ("David S. Herron") (03/01/91)
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.
kehres@ima.COM (Tim Kehres) (03/07/91)
> This "problem" exists for ALL implementations of UUCP. At least, > for all the ones I've seen (since V7), .... This does not appear to be the case. My experience with 4.3 BSD UUCP has shown this not to be true, and my tests with 4.2 have shown there not to be a problem as well. It seems to be limited to HDB (and possibly to the old System V version) of UUCP. > 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. This is fine as long as you are guaranteed of always routing your messages between machines that have these kind of bilateral agreements established. For the type of routing that is done these days, I do not believe that this is a reliable general solution. Any sites not having this type of bilateral agreement will still exchange mail using "uux rmail ...", many times resulting in the UUXQT failures. > >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. I disagree with this. Although it is important to check for permissions when doing file type activity, the HDB UUXQT is actually checking the argument list to rmail. Please note that the assumption that I am making is that we should be able to transfer 822 compatible messages across a UUCP link. If this is the case, the receiving UUCP site should handle legal 822. For the type of security you are refering to, if required for mail, this capability should be built into rmail (it is the one that has to determine if the address is a file or an encoded O/R name). Regards, Tim Kehres
david@twg.COM (David Herron) (03/07/91)
Tim et al, > > This "problem" exists for ALL implementations of UUCP. At least, > > for all the ones I've seen (since V7), .... > > This does not appear to be the case. My experience with 4.3 BSD UUCP has > shown this not to be true, and my tests with 4.2 have shown there not to > be a problem as well. It seems to be limited to HDB (and possibly to the > old System V version) of UUCP. Hmm.. I just glanced into the 4.3-tahoe source we have on line here and in chkpth.c:chkpth() was code which looked exactly as I expected. Namely, it checks a string to see if its prefix is in the "path table" which is read out of USERFILE. It presumes that the string is a rooted path name & fails if it doesn't begin with a '/' & fails if it doesn't have a prefix in USERFILE. > > >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. > > I disagree with this. Although it is important to check for permissions > when doing file type activity, the HDB UUXQT is actually checking the argument > list to rmail. Please note that the assumption that I am making is that we > should be able to transfer 822 compatible messages across a UUCP link. If > this is the case, the receiving UUCP site should handle legal 822. For the > type of security you are refering to, if required for mail, this capability > should be built into rmail (it is the one that has to determine if the address > is a file or an encoded O/R name). No I still disagree. Every version of UUCP I am familiar with (my familiarity starts with V7..) has checked the arguments to remote command requests as if they were file names. `uuxqt' has no idea at all what sort of command it is executing .. it only cares that it executes it and gathers up its standard output & mails that back to the requestor. Therefore it cannot make the assumption that `rmail' is `safe' because everything on its command line is e-mail addresses -- it simply does NOT know this! Also note that X.400 addresses can contain all sorts of fun characters, some of which will cause problems when passed through a /bin/sh command line. This is another little detail of doing commands via UUCP -- that commands are executed via a shell. One of the problems in doing RFC-822 this way is that occasionally some vital quoting is lost. This problem will be worse with X.400. At any rate I can't fault UUCP for erring on the side of caution, even if its slightly paranoid caution. And yes you can > Please note that the assumption that I am making is that we > should be able to transfer 822 compatible messages across a UUCP link. with the caveat that quoting will be stepped upon. This is done thousands, if not millions, of times a day in the UUCP portion of the matrix. David
kehres@ima.COM (Tim Kehres) (03/07/91)
David, > > > This "problem" exists for ALL implementations of UUCP. At least, > > > for all the ones I've seen (since V7), .... > > > > This does not appear to be the case. My experience with 4.3 BSD UUCP has > > shown this not to be true, and my tests with 4.2 have shown there not to > > be a problem as well. It seems to be limited to HDB (and possibly to the > > old System V version) of UUCP. > > Hmm.. I just glanced into the 4.3-tahoe source we have on line here > and in chkpth.c:chkpth() was code which looked exactly as I expected. > Namely, it checks a string to see if its prefix is in the "path table" > which is read out of USERFILE. It presumes that the string is a rooted > path name & fails if it doesn't begin with a '/' & fails if it doesn't have > a prefix in USERFILE. The 4.3-tahoe source I believe came out after the original 4.3 release. My understanding is the tahoe (and then reno) stuff is all post 4.3 and not identical. It could very well be that these versions have attempted to emulate the HDB software in this regard. Aside from looking at source code fragements, actually try to send messages through this software. This is what I have done, and as stated, encoded O/R addresses *do* get properly passed with stock 4.2 and 4.3 UUCP's. In the end the only thing that matters is the behavour of the software, not an individual code fragement. Regarding the validity of UUCP security checking in this context: > No I still disagree. Every version of UUCP I am familiar with (my familiarity > starts with V7..) has checked the arguments to remote command requests as > if they were file names. `uuxqt' has no idea at all what sort of command > it is executing .. it only cares that it executes it and gathers up its > standard output & mails that back to the requestor. Therefore it cannot > make the assumption that `rmail' is `safe' because everything on its command > line is e-mail addresses -- it simply does NOT know this! Again, please try sending these types of messages through the various types of UUCP, and you will find that the behavour differs depending upon the version. Regarding UUXQT knowing what it is executing, the folks at ISC looked into the HDB code, and found that this was not really the case. If you think about it for a bit, UUXQT has to know, since what it runs is controlled by the contents of the Permissions file. All it has to do is to check for rmail, and if this is the case, let rmail handle any error checking. > Also note that X.400 addresses can contain all sorts of fun characters, some > of which will cause problems when passed through a /bin/sh command line. This > is another little detail of doing commands via UUCP -- that commands are > executed via a shell. Sorry, I don't buy this one either. The messaging world is much bigger than just those hosts running UNIX. It is not proper to make rules (or artificial limitations) based upon what type of host your message may be automatically routed through. From my experience with UUCP (much longer than I wish to admit), I have yet to see messages get lost (or bounce) due to this type of problem. Note that I am not saying it is impossible, just not something that is a practical concern at this time. > occasionally some vital quoting is lost. This problem will be worse with X.400. > > At any rate I can't fault UUCP for erring on the side of caution, even > if its slightly paranoid caution. And yes you can If there is quoting present in the rmail command, this is an error on the side of originating UUCP side. Just as in 821, there are times where the comments and phrases of 822 are not proper - namely in the envelopes. > > Please note that the assumption that I am making is that we > > should be able to transfer 822 compatible messages across a UUCP link. > > with the caveat that quoting will be stepped upon. This is done thousands, > if not millions, of times a day in the UUCP portion of the matrix. Address of the form: "Full Name" <user@host.domain> are not passed in this form through rmail, but rather in the message header. What is passed through rmail is "user@host.domain". Regards, Tim Kehres P.S.: Perhaps the discussion of UUCP specific issues should be continued off this list since it is probably not of general interest to this list.
dvv@hq.demos.su ("Dmitry V. Volodin") (03/13/91)
IMHO it's not uuxqt's business to verify security. It's sysadm's
part of work. And HDB uuxqt doesn't care a damn about quoting.
--
Dmitry V. Volodin <dvv@hq.demos.su> |
fax: +7 095 233 5016 | Call me Dima ('Dee-...)
phone: +7 095 231 2129 |