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 7, 2017, at 3:08 PM, admin@??? wrote:
>
> Maybe it would be possible to avoid accepting further command line arguments
> after “-f“, but that doesn't seem sufficiently backwards-compatible.


No, but behaving like a minimal sendmail(1)-compatible CLI when argv[0]
ends in "sendmail", with Exim-specific extensions only otherwise, should
be backwards-compatible. Folks invoking sendmail(1) should not expect
Exim-specific behaviour, for that they should invoke "exim" or equivalent.

> However, it's not clear what performs the token splitting of the “-f” argument
> here. There's clearly a very significant bug in there somewhere in the stack.
> It's also rather strange that something would pass the “Host:” header contents
> unchanged to a sendmail invocation, even if it were a valid domain.
>
> On the other hand, Exim already supports the “--” option list terminator, so
> PHP (or whatever calls the sendmail program) just needs to follow recommend
> practices for constructing command lines:
>
> https://docs.fedoraproject.org/en-US/Fedora_Security_Team/1/html/Defensive_Coding/sect-Defensive_Coding-Tasks-Processes.html#idm225434989808
> (Robust argument list processing)


Yes, if PHP weren't the security nightmare that it is, and has always
been, you'd not need this. However, it is what it is, and shall remain
for a long time. Though the issue is not Exim's fault, it is not
unreasonable to provide a work-around in Exim, that helps make the
overall eco-system more secure.

Much of my recent spam has been via compromised PHP installations, so
fixing should ultimately help to reduce spam seen by non-broken Exim
systems that don't even have PHP.

So my advice is to grudgingly do something reasonably compatible that
blocks the Wordpress/PHP exploit vector in question.

-- 
    Viktor.