On 06/07/2023 22:30, Andrew C Aitchison wrote:
> On Thu, 6 Jul 2023, Jeremy Harris via Exim-dev wrote:
>
>> On 06/07/2023 17:21, Andrew C Aitchison via Exim-dev wrote:
>>> I'm writing a CLIENTID extension for exim which will
>>> add some variables to be used in the exim config.
>>>
>>> One of them, call it "token", is unsafe and cannot be safely untainted
>>> (it is a string of "between 1 and 128 printable characters") so I am
>>> thinking of exposing a second variable which is the string hex-encoded.
>>
>> That second one should also be tainted, in that case,
>
> Why should the hex-encoded version be tainted ?
Because it derives from attacker-source data, not verified
against local data.
> As an implementation detail it is currently untainted.
Effectively, you've introduced an untainting backdoor.
> If someone decoded the hex it would pose a risk,
> but I am prepared to assume that they will understand that they
> do that at their own risk.
>
> Exim is able to guarantee to the exim config that the hex-token is a
> string of (not more than 256) hex digits, so I don't see a need for it
> ti be tainted. Am I missing some other risk ?
It's more a matter of principle, allowing simple reasoning about
the provenance of the data.
> There is actually another variable which is "between 1 and 16
> characters comprised of only alphanumeric and dash characters" (ASCII
> by RFC5324, I think). I *was* assuming that this would also be an
> untainted variable.
Again, if this comes off the wire (or is derived from something that
does, don't do it.
>> so I don't see it buys you anything. But - why does it matter if
>> the value is tainted? How is it expected to be used?
>
> This token is somewhere between a username and a password.
> It is shared with the associated imap service.
> It is likely to appear in logfiles and be used as a rate-limit
> key and in block lists.
>
> I don't have much or recent experience with user databases, and they
> vary a lot, so I expect at least initially, that people will have to
> write their own configurations to integrate it with their user database
> and to communicate with the imap service (so that blocking or
> unblocking in one does the same in the other).
So long as you're only going to feed the datum to a DB, or external program
as an argument, there's no problem with it being tainted.
(Mostly because we can't control what these non-exim components do,
so have to give up on protection at that boundary).
> My observation from the exim lists is that people struggle to write
> configs that work with tainted variables, so it seems important to
> make safe variables available to the exim config.
"safe" by just abandoning the taint-tracking isn't something I really
want to end up with. The whole effort was put in place to keep exim
away from a log4j-style debacle (yes, we got burned by something similar).
>
> The overall point of the exercise is to be able to, say, disable a
> user's laptop but still allow them to read and send mail from their
> phone or web-mail, should exim or the imap service believe that the
> laptop is misusing the mail service.
Sounds like stashing (tainted) values in a DB, and comparing against a DB
suffices?
--
Cheers,
Jeremy
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
