Mailing List Archive

proactive exploit mitigation patches
Hi,

I wanted to share some simple patches I've written for Exim that make
exploitation of string expansion more difficult.

The first one adds a config option to globally disable "${run {...}}":

https://gist.github.com/ryancdotorg/2643c2662a7e0f7554ecec295fb23c0c

This hooks up a global "forbid_run" option up to some existing
mechanisms
to disable the functionality. It is off by default.

The second one doesn't have a config option, but simply adds global
restrictions to the "${perl {...}}" expansion to disable "private by
convention" functions (those that start with "_"), and access to
non-exported functions of modules that are in use.

https://gist.github.com/ryancdotorg/a5e66b3457e0297d70d28bc28648e531

This may benefit from being put behind a config option since in a small
number of cases may break existing configs. Having it throw a warning if
not enabled would probably be appropriate, though.

I welcome any feedback on these proposed changes.

-Ryan

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: proactive exploit mitigation patches [ In reply to ]
On 25/07/2019 17:16, Ryan Castellucci via Exim-dev wrote:
> I welcome any feedback on these proposed changes.

Without denying the possible value of such restrictions,
a more general protection against this class of exploits
has been developed, and hit the git repo yesterday:

f3ebb786e Track tainted data and refuse to expand it

--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: proactive exploit mitigation patches [ In reply to ]
Can we revisit whether it makes sense to add these?

The forbid_run patch is absolutely trivial.

The perl lockdown one, as I originally mentioned, probably needs to
be behind a config option.

From my previous email:

Hi,

I wanted to share some simple patches I've written for Exim that make
exploitation of string expansion more difficult.

The first one adds a config option to globally disable "${run {...}}":

https://gist.github.com/ryancdotorg/2643c2662a7e0f7554ecec295fb23c0c

This hooks up a global "forbid_run" option up to some existing
mechanisms
to disable the functionality. It is off by default.

The second one doesn't have a config option, but simply adds global
restrictions to the "${perl {...}}" expansion to disable "private by
convention" functions (those that start with "_"), and access to
non-exported functions of modules that are in use.

https://gist.github.com/ryancdotorg/a5e66b3457e0297d70d28bc28648e531

This may benefit from being put behind a config option since in a small
number of cases may break existing configs. Having it throw a warning if
not enabled would probably be appropriate, though.

I welcome any feedback on these proposed changes.

On 2019-07-26 10:52, Jeremy Harris via Exim-dev wrote:
> On 25/07/2019 17:16, Ryan Castellucci via Exim-dev wrote:
>> I welcome any feedback on these proposed changes.
>
> Without denying the possible value of such restrictions,
> a more general protection against this class of exploits
> has been developed, and hit the git repo yesterday:
>
> f3ebb786e Track tainted data and refuse to expand it
>
> --
> Cheers,
> Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##