Re: -x on Postfix, and a possible fix.

[Tony Shadwick]

On 06/07/2010 07:14 PM, Don Armstrong wrote:
> On Mon, 07 Jun 2010, Tony Shadwick wrote:
>  > In spamass-milter.cpp, you have this:
>  >
>  > /* open a pipe to sendmail so we can do address
>  > expansion */
>  >
>  > char buf[1024];
>  > char *fmt="%s -bv \"%s\" 2>&1";
>  >
>  > I changed it to be this instead:
>  >
>  > char *fmt="%s -q \"%s\" /etc/postfix/virtual 2>&1";
>
> You don't want to do this. This leads to the remote exploit of
> spamass-milter shown and fixed here:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573228
>
>  > Huh? Why are the < and > getting left on the address? I didn't
>  > comment anything out that got ride of them. Have they always been
>  > passed to sendmail -bv?
>
> sendmail is passed the envelope recipient directly as it is reported
> to spamass-milter; '<address@hidden>' is a perfectly legitimate envelope
> recipient.
>
>
> Don Armstrong
>
> --
> No matter how many instances of white swans we may have observed, this
> does not justify the conclusion that all swans are white.
> -- Sir Karl Popper _Logic of Scientific Discovery_
>
> http://www.donarmstrong.com http://rzlab.ucr.edu
>
> _______________________________________________
> Spamass-milt-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/spamass-milt-list

Although I must acknowledge this as a problem, this is somewhat the 
fault of a negligent systems administrator.  In order:

#1 Allowing postfix to mail directly to programs to begin with.

#2 Having -x set on a Postfix box doesn't even work properly at current, 
so there's no reason to do it - you will fork bomb yourself to oblivion 
as spamass-milter sits around waiting for sendmail -bv to return with 
proper info, which it never will.

#3 Allowing mail from without a ehlo/helo.

Example to my own host (ehlo left out - possibly the report did the same):

250-ENHANCEDSTATUSCODES
250-PIPELINING
250-8BITMIME
250-SIZE
250-DSN
250-ETRN
250-AUTH PLAIN LOGIN
250-STARTTLS
250-DELIVERBY
250 HELP
rcpt to: root+:"|touch /tmp/numbskitime"
503 5.0.0 Need MAIL before RCPT
mail from: <address@hidden>
250 2.1.0 <address@hidden>... Sender ok
rcpt to: root+:"|touch /tmp/numbskitime"
550 5.7.1 root+:"|touch /tmp/numbskitime"... Cannot mail directly to 
programs

My solution is really a bit pragmatic.  Yes, it does somewhat open the 
door.  I'm mostly done with a set of changes that allows you to pass -X 
instead of -x.  -X would then take an argument to a script that you can 
pass an envelope recipient to, and it will return a valid user whose SA 
prefs would be used, or null.

I guess I'm wondering where the responsibility of the milter author lies 
when a misconfigured system is set up this way.  At the end of the day, 
there's not a situation that will ever arise where -x is appropriate, 
and for my example, I have a perl script that strips the <> from the 
envelope, and then calls postmap -q (content left in the envelope) 
/etc/virtual.

So with their example exploit, you would have 3 hurdles.

#1 - will the mta allow you to do this.  Attempting to do this to a 
(more or less stock) Ubuntu configuration yeilds:

rcpt to: root+:"|touch /tmp/numbskitime"
504 5.5.2 <root+:|touch /tmp/numbskitime>: Recipient address rejected: 
need fully-qualified address
rcpt to: <root+:"|touch /tmp/numbskitime">
504 5.5.2 <root+:|touch /tmp/numbskitime>: Recipient address rejected: 
need fully-qualified address

So no, the administrator needs to do something a bit dumb to allow this 
to happen.

#2 If the administrator was dumb enough to let the above happen, what 
does spamass-milter do with it?  Well, with -x, the following gets run:

sendmail -bv root+:|touch /tmp/numbskitime

On both postfix and sendmail, this does in fact work.  I'm not certain 
as to why right offhand, as it really should not.  That's a problem. 
Now, given that someone did -X with my code and happened to write a 
script that essentially called "sendmail -bv".  That's a problem.  In my 
case however, I'm calling postmap.  Trying that yields:

postmap -q "root+:|touch /tmp/numbskitime" /etc/postfix/virtual

Nothing.  No temp file gets dropped.  It just returns null.

So in short, my mod is (so far) harmless.  One can put themselves in a 
bad spot, but if so, they did it to themselves. :\

So far as fixing -x...I just don't know.  Maybe some sanity checking to 
make sure that there are no pipe symbols in the address being passed 
through?

Tony Shadwick