This can lead to code injection via a malicious configuration file, for example:
[report_store]
backend = SQL; print `whoami`;
Because the configuration file is loaded first from the current working directory (as mentioned in a previous issue: https://github.com/msimerson/mail-dmarc/issues/231), the code injection could be abused to gain privileges on a system where the library is executed as a privileged user in a world-writable directory (e.g. /tmp).
Although the above is a somewhat unlikely scenario, I would still advise to switch to Module::Load for safer dynamic loading and to avoid loading the configuration file from the current working directory (maybe instead use $HOME/.mail-dmarc.ini).
Describe the bug
The dynamic loading of the backend module uses an unsafe form of eval without sanitizing the module name from the config file. https://github.com/msimerson/mail-dmarc/blob/ac6d3ad2e50c79a409c0fc642ffc2816c2018827/lib/Mail/DMARC/Report/Store.pm#L43
This can lead to code injection via a malicious configuration file, for example:
Because the configuration file is loaded first from the current working directory (as mentioned in a previous issue: https://github.com/msimerson/mail-dmarc/issues/231), the code injection could be abused to gain privileges on a system where the library is executed as a privileged user in a world-writable directory (e.g. /tmp).
Although the above is a somewhat unlikely scenario, I would still advise to switch to
Module::Loadfor safer dynamic loading and to avoid loading the configuration file from the current working directory (maybe instead use$HOME/.mail-dmarc.ini).