Now that I have figured out that I was wrong to follow the advice of
Randall Munroe and Mrs. Roberts https://xkcd.com/327/
"I hope you've learned to sanitize your database inputs."
Instead we should *let the database routines* sanitise our data.
I agree with Jeremy's ponts below have removed the detainting.
> Sounds like stashing (tainted) values in a DB, and comparing against a DB
> suffices?
I think so.
Though the impression I get is that many people get caught with tainted
data when they use database lookups or run external commands.
On Thu, 6 Jul 2023, Jeremy Harris via Exim-dev wrote:
> 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/
>
--
Andrew C. Aitchison Kendal, UK
andrew@???
--
## 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/
