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
andrew@???
