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
