0

I'm upgrading an exim4 installation which has some custom filters, to Debian 11. (Specifically, the filters are this.)

Since that uses Exim 4.94, I've now run into the new-ish "tainted variables" 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.

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:

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?

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!

I should add: I can't use a file lookup, because this valid list needs to be configured dynamicially, outside of exim4 configuration files.

wu-lee
  • 105
  • 3

2 Answers2

0

${quote_... do not do de-tainting.

and exim tainting is on whole strings, so

in

/var/spool/exim4/db/disposable-aliases.db \
    select default_remaining from stem_configs \
    where stem = '${quote_sqlite:$local_part}'

The '${quote_sqlite:$local_part}' is still tainted and the taint spreads to the filename breaking the lookup.

the exim spec says you can put the filename immediately after the word 'sqlite' (outside of the braces containing the query)

[...] allows separate files for each query, [...] use an option appended, comma-separated, to the “sqlite” lookup type word. The option is the word “file”, then an equals, then the filename

${lookup sqlite,file=/var/spool/exim4/db/disposable-aliases.db \
    {select default_remaining from stem_configs \
    where stem = '${quote_sqlite:$local_part}'}

exim spec 9.26 - more about sqlite

The method that you are currently using is so deprecated that it is no-longer documented.

Jasen
  • 621
  • 5
  • 12
  • Thanks - I've also asked on the Exim-users list, and the answers there essentially concur with yours, although I do still have some comments, which I'll add in a separate reply. See https://www.mail-archive.com/exim-users@exim.org/msg57596.html – wu-lee Aug 22 '22 at 10:12
  • yeah, I saw that :) – Jasen Aug 22 '22 at 10:26
0

Just to add to @Jasen's answer (use the new sqlite lookup syntax, and the problem goes away), there are some wrinkles depending on the version of Exim in use:

  • Exim's error seem to be misleading here - the problem is tainted data, but source is not the file path, as it suggests.
  • I believe taint checking was first added in Exim 4.93 (from src/README.UPDATING and also checking for the word "taint" in the source code history)
  • Exim 4.94 has the sqlite_dbfile global setting implemented, but not support for the file= option for the lookup. So there's no way to use the newer syntax and have more than one sqlite database. (This is from my experience using 4.94.2 currently in Debian 11, and specifically mentioned here, bourne out checking the source history)
  • Support for the file= option only comes in Exim 4.95 (ditto; the commit is here).
  • Exim 4.94's error also is misleading if you try to use the file= option: it says 'absolute file name expected for "sqlite" lookup', even if the file name is untainted and absolute.

(Most of this comes from the thread discussion here)

wu-lee
  • 105
  • 3