Re: Making pglister work with exim 4.96+

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Célestin Matte <celestin(dot)matte(at)cmatte(dot)me>
Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, PostgreSQL WWW <pgsql-www(at)lists(dot)postgresql(dot)org>
Subject: Re: Making pglister work with exim 4.96+
Date: 2024-06-19 14:32:24
Message-ID: CABUevEwMXZ=q7yUqMwecTUz9MNn=sewNqS1N2nAn5cAbFy+yJg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-www

On Wed, Jun 19, 2024 at 11:29 AM Célestin Matte <celestin(dot)matte(at)cmatte(dot)me>
wrote:

> > Yeah, and I don't see why they would? The reason they do the taint
> marking in variables used in commands and filenames is that it would be a
> potential venue for attackers to inject things. No such vulnerability
> exists with environment variables. 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 responsible for 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
>

How is the data dangerous?

I mean, we pass the body of the email to inject.py as well, and that's also
under control of the sender. And if that's a problem, they'd have to remove
the entire pipe transport completely, which I really doubt wil lhappen...

The data is only dangerous when potentially badly escaped for e.g. a
commandline. Passing it in an environment variable does not have that
problem.

> Yeah, this seems extremely fragile. Concurrent delivery is a common
> thing, and not the only potential problem I bet. The proper fix surely is
> to make invoke.py work properly.
>
> What's invoke.py? Do you mean inject.py?
>

Yes.

I'm aware of the potential concurrency issues. One fix could be to only
> process emails in mailqueuehandler.py if their sender address is not empty
> (or we could add a boolean field for that purpose).
>

I mean, yeah, we could. But it still adds a complexity and fragitlity, for
from what I can tell zero actual gain.

> 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.
>

Oh. But we need the actual message-id. Having the exim internal one is of
no value.

> 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 (provided it's
> still queued at that point?)
>

I still completely fail to see why this complexity is a good idea.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>

In response to

Responses

Browse pgsql-www by date

  From Date Subject
Next Message Tom Lane 2024-06-19 15:10:04 Re: Governance directory page for pg.o
Previous Message Joe Conway 2024-06-19 14:10:20 Re: Governance directory page for pg.o