On Mon, 29 Jan 2007, Edward Pilatowicz wrote:
fyi, mailtool was eol'd a long time ago.
Thank goodness!
it's these times i think that solaris
application backward compatability forever promises isn't such a great
thing. ;)
No offense intended, but I have a difficult time taking Sun's promise of
"application backward compatibility forever" seriously.
First there was the switch from BSD to SVR4. Among other things, this
deleted the native flock() system call. Solaris has a flock() C function
which calls fcntl() locking internally; however the result does not have
the same semantics as flock(). [Long tirade available on why fcntl() is
not equivalent to flock()...]
It became necessary to check for a file being on an NFS structure in order
to avoid the fragile lockd/statd mechanism. With NFSv2, this was done
with the ustat() call, which was *documented* to return -1 in the returned
f_tinode value for NFS structure.
This facility of ustat() broke in NFSv3. Now the only way is to use the
fstatvfs() call, and check to see what is in the f_basetype string.
[You can't use fstatfs() because fstatfs() is documented as being
deprecated in SVR4, has different calling conventions, and returns
different statfs structs -- on Solaris it returns a short called f_fstyp
but on AIX it's an int called f_type that is always 0.]
Then, with the introduction of large filesystems, fstatfvs() broke; it now
returns EOVERFLOW. Never mind that the application doesn't care about the
values that overflowed. Applications must now all be changed to use the
new fstatvfs64() call.
so is your concern here that other MDAs might not filter out or
regenerate correct Content-Length header entries and hence
you feel that UW imap needs to propect itself againt them?
It isn't a matter of "other MDAs might not filter out or regenerate" -- it
is a matter of "other MDAs do not filter out nor regenerate"
could you provide some examples of other mail delivery
paths so that i could better understand the security implications?
The issues to consider are: is mail.local the only MDA on the system?
More importantly, is it the only program that is capable of acting as an
MDA?
Have you checked such things as /bin/mail, /usr/ucb/Mail, procmail,
various MUAs that are setgid mail?
Have you audited all setuid root programs and setgid mail programs to make
sure that they either filter/regenerate Content-Length or are incapable of
acting as an MDA?
There's a lot that a system administrator needs to check, and a lot that
he needs to keep his eyes on in the future. The admin has to watch
out in particular for installations of MUA packages that some user wants
that installs setgid mail (assuming that you run that way).
Setgid mail is particular tricky, because such programs rarely are audited
as well as setuid root programs. All too often, MUAs are given setgid
mail without people realizing that that is essentially the key to
everything elese.
More importantly, the attacker can manipulate what the recipient does NOT
see. I once demonstrated how an attacker could cause a message to be
lost, even when there was code to recognize an incorrect "landing" and
disregard the Content-Length. It just required the attacker to monitor
the victim until the to-be-lost message was delivered, and then deliver
the right sized suffix to set up a good "landing".
so is this type of attack possible with an MDA that correctly regenerates
Content-Length header fields?
It required finding an MDA that didn't. That was an easy task since
nobody thought to look for such a thing on the system in question.
By the way, it is *FAR* more common for MDAs (and MUAs!) to take action
with lines that start with "From " than to take action on Content-Length.
Just about every MUA/MDA (except for Sun's...) does the former...
this option is on my list of possibilities, it's just further down
the list since it has a larger impact on my user community.
Good luck. I don't envy your position between a rock and a hard place.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
