>Darren Reed <avalon @
coombs .
anu .
edu .
au> writes:
>|mail from: bin
>|250 bin... Sender ok
>|rcpt to: | sed 's 1,/^$/d' | sh
>|250 | sed 's 1,/^$/d' | sh... Recipient ok
>|data
>|354 Enter mail, end with "." on a line by itself
>|echo "+ +" > /usr/bin/.rhosts
>
>What I wander - would splitting the handling of mail (as, for instance, is
>possible in the TIS Firewall Toolkit) prevent such attacks? Can such a
>scheme (of splitting mail handling) with some more changes (e.g, to somehow
>run sendmail without root privelages) prevent it?
We can't block this kind of attack with our (current) stuff.
Believe me, we're as unhappy about this as the rest of the world.
It's some consolation that the mail processing on our bastion host
doesn't run as anyone more privileged than an ordinary user, but
it's still very unpleasant to contemplate bugs that let someone
run shell scripts on your machine through your mailer. :(
I think that the software model of splitting components up
still helps somewhat. Some headscratching has been taking place as
to whether it's a good idea to put some "bad address" scanning in
smap or smapd that looks for pipe symbols and other bad things in
incoming mail and reroutes it to Postmaster. That way, the security
perimeter machine would essentially filter bad addresses and
protect all the machines on the inside network. Whitehouse.Gov's
version of smap does some simple scans for invalid sender addresses:
>220 whitehouse.gov SMTP/smap Ready.
>Mail From: clinton
>250 clinton... Sender Ok
>Rcpt To: mjr @
tis .
com
>550 Recipient must be in form of: user, user @
eop .
gov, or user @
whitehouse .
gov
Something similar could be added to search for pipe marks,
or other weirdnesses. It would mean parsing RFC822 addresses (happy,
happy, joy, joy).
The problem, of course, with this approach, is that it's a
purely reactive measure. One of the things we tried to do with the
firewall toolkit was avoid patching our way around problems if we
possibly could, by coming up with ways of engineering a solution
to more general problems. In this case, scanning addresses for
pipe marks covers one known hole -- but we would still have to wonder
if there's another hole that we don't know about. This is the situation
I refer to as "the arms race" where you're at the mercy of whoever
knows more about the bug-state of your system. That's a bad situation
to be in!!
I may add some simple scanning to smapd to have it look for
bad patterns and reroute the mail to Postmaster. Before doing that,
we've got to do some head scratching and see if there's a general
solution to the problem that's more elegant.
mjr.
Follow-Ups:
|
|
