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):
## [email protected]
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
--
Andrew C. Aitchison Kendal, UK
[email protected]
--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## [email protected]
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
