On Fri, 19 Aug 2022, Nick via Exim-users wrote:
Hello Exim users,
I've a problem with Sqlite lookups and tainting. I've composed a question on
Stack Exchange, since it's easier to access than this list (and I forgot i
was already subscribed here long ago!)
https://serverfault.com/questions/1108609/does-exim4s-sqlite-quote-expansion-de-taint-the-expanded-value
Quoting that here:
I'm upgrading an exim4 installation which has some custom filters, to
Debian 11. (Specifically, the filters are this
<https://github.com/wu-lee/exim-disposable-aliases>.)
q>>
Since that uses Exim 4.94, I've now run into the new-ish "tainted
variables"
<https://www.exim.org/exim-html-current/doc/html/spec_html/ch-concept_index.html>
feature, which has broken my filter. Checking Exim in debug mode with
|exim4 -bdf -d+filter| the error is referring to a tainted filename (some
linebreaks added for readability):
|102536 LOG: MAIN PANIC 102536 Tainted filename for search
'/var/spool/exim4/db/disposable-aliases.db' 102536 Filter error: failed to
expand "${lookup sqlite{/var/spool/exim4/db/disposable-aliases.db \ select
default_remaining from stem_configs \ where stem =
'${quote_sqlite:$local_part}'} {$value}{0}}" in add command: NULL 102536
Filter: end of processing |
In this case, the reference to a filename /seems/ to be spurious, as
firstly the filename is hard-wired (so can't be tainted?) and secondly, if
I replace the |'${quote_sqlite:$local_part}'| portion of the query with a
literal value, the error stops (at least from this particular lookup).
My suspicion therefore is that it's actually the presence of |$local_part|
in the query which is the problem, and not the filename.
Agreed.
I have discovered there's an untainted version of |$local_part| available
in some circumstances, |$local_part_data| - however in my circumstance, it
isn't being set and so isn't useful.
More searching finds this assertion in the Exim4 documentation here
<https://www.exim.org/exim-html-current/doc/html/spec_html/ch-file_and_database_lookups.html>:
If tainted data is used in the query then it should be quuted
[sic] by using the ${quote_:} expansion operator appropriate for
the lookup.
This seems to imply that the |${sqlite_quote: .. }| expansion should be
de-tainting the content of |$local_data|. That would seem sensible, but is
this actually correct, given that if I replace the expansion with a literal
the tainting problem stops?
If |${sqlite_quote: .. }| really is de-tainting its result, then what is
causing this look-up to be rejected?
Did you mean quote_sqlite ?
spec.txt 9.26 says:
The only character affected by the quote_sqlite
operator is a single quote, which it doubles.
so I doubt that it is intended to detaint,
but my knowledge of SQL is very limited.
If it is not, then what other recourse do I have? The sqlite look-up above
is actually /designed/ to validate the local part against a list of valid
values stored in the database, and should be able to de-taint the value!
Looking again at section 9.26, you are using the deprecated method of specifying
the filename. If you replace
${lookup sqlite{DISP_ALIASES_DB
with
${lookup sqlite,file=DISP_ALIASES_DB {
(in about a dozen places) or set the sqlite_dbfile main option
rather than specifying the filename in each lookup, I think that will satisfy
exim.
However I am not certain that it will guarantee to avoid looking up Bobby
Tables.
Thanks!
Nick
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
