On 06/08/2010 08:53 AM, Tony Shadwick wrote:
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; '<[email protected]>' 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 > [email protected] > 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: <[email protected]> 250 2.1.0 <[email protected]>... 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 _______________________________________________ Spamass-milt-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/spamass-milt-list
FWIW - I've attached a patch that creates the -X option. The problem is - it segfaults if you try to run with -X. I'm not a c programmer, I'm a perl programmer, so I've hunted this down as far as I can with gdb, and here's where the problem lies according to gdb:
------------------------------------------------------------Starting program: /usr/local/sbin/spamass-milter -d misc,rcpt -i 127.0.0.1/32 -i 172.16.30.0/24 -i 172.16.40.0/24 -r 10 -u nobody -X /home/tshadwick/perl-scripts/postfix-address-verification
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6f01022 in ?? () from /lib/libc.so.6
(gdb) backtrace
#0 0x00007ffff6f01022 in ?? () from /lib/libc.so.6
#1 0x00007ffff6f00d46 in strdup () from /lib/libc.so.6
#2 0x000000000040915f in main (argc=17, argv=0x7fffffffe5b8)
at spamass-milter.cpp:277
(gdb) up
#1 0x00007ffff6f00d46 in strdup () from /lib/libc.so.6
(gdb) list
174
175 #if defined(__FreeBSD__) /* popen bug - see PR bin/50770 */
176 static pthread_mutex_t popen_mutex = PTHREAD_MUTEX_INITIALIZER;
177 #endif
178
179 // {{{ main()
180
181 int
182 main(int argc, char* argv[])
183 {
(gdb) up
#2 0x000000000040915f in main (argc=17, argv=0x7fffffffe5b8)
at spamass-milter.cpp:277
277 custom_expand_command = strdup(optarg);
(gdb)
------------------------------------------------------------
Apparently I'm hosing up the command line assignment. I've hunted it
high, low, and sideways without success. I'm sure someone that knows
c++ will see my error right away, but I'm going nuts on it.
ANYWAY - I'm open to discussing the situation further. Obviously I don't want to leave a remote root exploit sitting out there, but then again, I kinda need to be able to resolve addresses to users. :)
Tony Shadwick
spamass-milter.cpp.patch.gz
Description: GNU Zip compressed data
_______________________________________________ Spamass-milt-list mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/spamass-milt-list
