Re: [exim-dev] [Bug 2118] sendmail -be and ${run} macro secu…

Pàgina inicial
Delete this message
Reply to this message
Autor: Viktor Dukhovni
Data:  
A: exim-dev
Assumpte: Re: [exim-dev] [Bug 2118] sendmail -be and ${run} macro security problem

> On May 5, 2017, at 5:41 PM, Andrew C Aitchison <andrew@???> wrote:
>
> On Fri, 5 May 2017, admin@??? wrote:
>
>> https://bugs.exim.org/show_bug.cgi?id=2118
>>
>> --- Comment #5 from Heiko Schlittermann <hs@???> ---
>> (In reply to Sandor Takacs from comment #0)
>>> I found this WordPress + Exim remote code execution exploit on exploit-db
>>> site. It uses "exim -be '${run...}'" to place payload on the remote system.
>>>
>>> https://exploitbox.io/vuln/WordPress-Exploit-4-6-RCE-CODE-EXEC-CVE-2016-
>>> 10033.html
>>
>> It's remote character is a Wordpress problem. A remote attacker can run
>> commands on the Wordpress site. Exim is one of the commands, but not the only
>> one. Probably an attacker can even run "cat", "touch" and so on. Where is the
>> vulnerability? Are "cat", "touch", and so on, no vulnerable? Or is Wordpress
>> vulnerable?
>
> I'm guessing that the exim/sendmail command name is set in the wordpress config and not under the hacker's control.
>
> This "exploit" hides the "/" (and any other character that can be reliably got from exim -be) from whatever sanity checking wordpress
> is doing on the command-line args.
> That is a genuine (though small) increase in exposure
> but it is not a problem of exim,
> but of wordpress + exim being more than the sum of the two parts.
>
> Perhaps, exim could have a config option to disable -be and ${run}
> for use in situations when its command line options are untrustworthy,
> but that is being nice and covering someone-else's back.


Though the issue is definitely with PHP/Wordpress, it might be prudent/polite
to attempt to do something about it, if at all possible. In Postfix, due to
related concerns, Wietse restricted which "-C" options are valid with the
sendmail(1) command:

    20161227


        Safety: the sendmail -C option must specify an authorized
        configuration directory: the default configuration directory,
        a directory that is listed in the default main.cf file with
        alternate_config_directories or multi_instance_directories,
        or the command must be invoked with root priveleges.  This
        mitigates a problem with the PHP mail() function.  Files:
        global/mail_conf.[hc], sendmail/sendmail.c.


One workaround would be to only process "-be" when invoked as "exim", ...
and not when the last path component argv[0] is "sendmail".

-- 
    Viktor.