Mailing List Archive

[Bug 2737] New: $mime_filename considered as Tainted
https://bugs.exim.org/show_bug.cgi?id=2737

Bug ID: 2737
Summary: $mime_filename considered as Tainted
Product: Exim
Version: 4.94
Hardware: All
OS: All
Status: NEW
Severity: bug
Priority: medium
Component: ACLs
Assignee: jgh146exb@wizmail.org
Reporter: warren@percol8.co.za
CC: exim-dev@exim.org

As per the documentation
https://www.exim.org/exim-html-current/doc/html/spec_html/ch-content_scanning_at_acl_time.html#SECTscanmimepart
the option 'decode = $mime_filename' can be used however within the MIME ACL.
This now fails due to the filename being tainted.

Here is a quick test with an attachment using the below mime ACL:

acl_check_mime:

warn
decode = $mime_filename
logwrite = :main: DEBUG: Filename $mime_filename

accept


10:59:27 10347 using ACL "acl_check_mime"
10:59:27 10347 processing "warn"
(/home/warren/exim/exim-4.94.2/src/configure.default 642)
10:59:27 10347 ?considering: $mime_filename
10:59:27 10347 ???expanding: $mime_filename
10:59:27 10347 ??????result: myspreadsheet.xlsx
10:59:27 10347 ???(tainted)
10:59:27 10347 check decode = $mime_filename
10:59:27 10347 = myspreadsheet.xlsx
10:59:27 10347 LOG: MAIN PANIC
10:59:27 10347 Tainted filename
'/var/spool/exim/scan/1leZql-0002gt-L3/myspreadsheet.xlsx'
10:59:27 10347 warn: condition test deferred in ACL "acl_check_mime"


Using 'decode = default' solves the issue and the documentation also does
mention "However, you should keep in mind that $mime_filename might contain
anything.". So not sure how this should be dealt with. I can only see 2
options:

1. Remove the ability to use decode = $mime_filename or
2. Remove the taint check on $mime_filename and warn the OP that this is
dangerous (this is probably not a good idea)


Is there an alternative approach?

--
You are receiving this mail because:
You are on the CC list for the bug.
Re: [Bug 2737] New: $mime_filename considered as Tainted [ In reply to ]
On Thu, 6 May 2021, admin--- via Exim-dev wrote:

> As per the documentation
> https://www.exim.org/exim-html-current/doc/html/spec_html/ch-content_scanning_at_acl_time.html#SECTscanmimepart
> the option 'decode = $mime_filename' can be used however within the MIME ACL.
> This now fails due to the filename being tainted.
... ...

> Using 'decode = default' solves the issue and the documentation also does
> mention "However, you should keep in mind that $mime_filename might contain
> anything.". So not sure how this should be dealt with. I can only see 2
> options:
>
> 1. Remove the ability to use decode = $mime_filename or
> 2. Remove the taint check on $mime_filename and warn the OP that this is
> dangerous (this is probably not a good idea)
>
>
> Is there an alternative approach?

Yes. Detaint in the usual way, probably with a lookup.

If you are decoding the mime file with its real name you must
have a reason, perhaps to make them available on a web page.
It would then be reasonable to check that the filename was
sensible in that context.
I wouldn't see a database looking as the mot obvious way to sanitize
the filename, but we do already have the tools to turn a pattern
matching into a lookup, so the flexibility is there.

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [Bug 2737] New: $mime_filename considered as Tainted [ In reply to ]
On Thu, May 6, 2021 at 12:57 PM Andrew C Aitchison via Exim-dev <
exim-dev@exim.org> wrote:

>
> > Is there an alternative approach?
>
> Yes. Detaint in the usual way, probably with a lookup.
>
> If you are decoding the mime file with its real name you must
> have a reason, perhaps to make them available on a web page.
> It would then be reasonable to check that the filename was
> sensible in that context.
> I wouldn't see a database looking as the mot obvious way to sanitize
> the filename, but we do already have the tools to turn a pattern
> matching into a lookup, so the flexibility is there.
>


Thanks Andrew. It actually never occurred to me to even try and specify a
lookup after decode = ... - which indeed works just fine and addresses the
issue.
Just fyi, the file name is needed for an external application that does
further analysis and reporting.

--
.warren
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##