> Yeah, and I don't see why they would? The reason they do the taint marking in variables used in commands and
filenamesis that it would be a potential venue for attackers to inject things. No such vulnerability exists with
environmentvariables. Obviously the receiving code, whether a shellscript or a python program or a c program or
whatever,can have injection vulnerabilities of it's own, but the passing values layer (which is what Exim is
responsiblefor there) does not.
Yet this is what we want to do here: bypass security protection by passing dangerous data through environment
variables.It would make sense for them to prevent that usage
> Yeah, this seems extremely fragile. Concurrent delivery is a common thing, and not the only potential problem I bet.
Theproper fix surely is to make invoke.py work properly.
What's invoke.py? Do you mean inject.py?
I'm aware of the potential concurrency issues. One fix could be to only process emails in mailqueuehandler.py if their
senderaddress is not empty (or we could add a boolean field for that purpose).
> And the above doesn't actually solve the problem does it? It still requires passing the message-id which is a tainted
variable?
$message_id is not the header, it's exim's internal message ID and is untainted.
Here's my current version, handling the header as well:
event_action = ${if eq {msg:delivery}{$event_name} {${lookup pgsql{update incoming_mail set
sender='${quote_pgsql:$sender_address}',messageid='${quote_pgsql:$header_message-id:}' where
messageid='${quote_pgsql:$message_id}';notify incoming; update bounce_mail set sender='${quote_pgsql:$sender_address}',
messageid='${quote_pgsql:$header_message-id:}'where messageid='${quote_pgsql:$message_id}'; notify bounce}} {}}}
Another overall solution may be to fetch header_message-id and sender_address from exim in inject.py using a subprocess
(providedit's still queued at that point?)
--
Célestin Matte
