[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CORE/EDGE Re: Content-length: - Re: Implementing SMTP server
< From: Ned Freed <NED@SIGURD.INNOSOFT.COM>
<< Has ATTmail been broken into from the Internet? If it was, would you be
<< allowed to tell us about it?
< I don't know anything about X.400 in the ATTMail context, but there have
< been a variety of amusing problems with ATTMail, some security related. My
< personal favorite was the "enhanced security" version of UUXQT (portions
< of ATTMail are/were based on UUCP) that rejected any address that began
< with a slash because it could be an absolute file name reference. There
< was even attempt to rewrite RFC1327 to "fix" this -- the response was to
< fix the broken security hack rather than screw a perfectly reasonable
My understanding of the leading / problem is that it actually dates back to
the introduction of uucp back in the early days of Unix. If you execute the
uux - foo!rmail (/bar)
the uuxqt on the machine foo will see instructions to execute the command
rmail passing it the contents of the file /bar. The man page still describes
using uux in this fashion:
"As an example, the command
uux "!diff sys1!/home/dan/file1 sys2!/a4/dan/file2 >
will get the file1 and file2 files from the ``sys1'' and
``sys2'' machines, execute a diff(1) command and put the
results in file.diff in the local PUBDIR/dan/ directory.
PUBDIR is a public directory defined in the uucp source. By
default, this directory is /var/spool/uucppublic
"uux will attempt to get all appropriate files to the specified
system where they will be processed. For files that are
output files, the file name must be escaped using parentheses.
For example, the command:
uux "a!cut -f1 b!/usr/file > c!/usr/file"
gets "/usr/file" from system "b" and sends it to system "a",
performs a cut command on that file and sends the result of
the cut command to system "c".
"uux will notify you if the requested command on the remote
system was disallowed."
If I do a command like the above on my unix system, I get a message from
remote execution [uucp job pegasusA6d1a (3/22-22:51:29)]
file access denied to pegasus!hansen
So the problem mentioned here isn't specific to AT&T Mail.
< The best known problem with ATTMail wasn't security related, but it did
< have service denial characteristics that brought it into the security
< realm. I'm referring, of course, to the period of time during with
< ATTMail would reject any message with a MIME content-type header. This was
< a major hassle for us to deal with, and we are still grappling with the
< fallout of that since so many configurations were modified to drop
< essential message information in the interests of getting the mail through
< in some form.
Service denial can be a low level security risk when it's possible for it to
be used to determine who can and who cannot be allowed to do something. I
don't think that applies in this case.
On the other hand, AT&T Mail did fix that problem fairly quickly (for them)
after it was idenfied.