Curtis Villamizar wrote:
> Since pcre evaluates in order you could add>
> /^Content-(Disposition|Type).*;??x-apple-part-url="[^"]+"$/x DUNNO
>
> before the pcre that does the rejection.
That's one possibility, but:
(a) you probably won't want the '??' qualifying the ';'. '??' in the
Postfix log sample I mentioned just symbolises a CRLF line break.
Postfix/cleanup concatenates header lines, so either '\s*' or '\r?\n\s+'
will match such a 'fold' in the headers in a PCRE.
(b) there may be alternative or additional parameters to look out for,
not just x-apple-part-url;
(c) that table entry allows malware to pass any block, if it adds some
'x-apple-part-url=' string after or as part of an executable filename.
I still prefer the solution below, which specifies the character classes
for Content-* parameters and so prevents the false match.
Is there anywhere else I should raise this as a documentation bug?
In general, wherever you see a '.*', IMHO you should ask what exactly
the syntax of the string is you're matching against, or if it is free
text at least limit it to a '.{0,n}' quantifier. This avoids lack of
specificity, possible combinatorial explosion and unnecessary resource
usage.
> Since "." is commonly "%2E" you could also change the "\." in the RE to
> "(\.|%2E)".
'=2E' (quoted-printable) was already in the examples in the existing
documentation and below, so maybe that should be '(\.|=2E|\%2E)'.
Probably '=2E' helps with encoded words in headers (RFC 2047), and maybe
also with MIME headers that are enclosed within another MIME entity that
specifies quoted-printable encoding.
Actually I'm not sure if any MUAs will regard '%2E' as a '.' unless the
parameter is a full RFC 6266 'filename*=' (not 'filename=') followed by
a character encoding name - in which case the file extension is quite
likely to be percent-encoded too.
> That doesn't solve base64 encoding.
No, it doesn't. As I understand it, postfix/cleanup is designed to be
fast and lightweight. man pages for body_checks and header_checks say
"they do not decode attachments", so presumably shouldn't be expected to
apply the various decoding mechanisms to the various header fields and
parameters including those indicating filenames.
So I would suggest, unless there's a real flood of .exe attachments,
moving these type of restrictions to something like SpamAssassin
'mimeheader' rules anyway, which does decoding first. These rules
should also not use a '.*' between the 'name=' and the extension, but
instead something like
(?:"(?:[^"]|\\")*|[^();:,\/<>\@\"?=<>\[\]\ ]*)
Besides catching evasions using various encodings, using SpamAssassin
may also have the advantage that specific malware can be picked up first
by an AV, before the slower SpamAssassin rules look for message
attributes and headers associated with generic malware.
In any case, be careful if trying to block filenames in header_checks.
> Disclaimer: I haven't tried this.
>
> Curtis
>
> On 04/06/16 22:02, Laz C. Peterson wrote:
>> This is great information.
>>
>> It's very odd ... Apple has been responsible for the foundation of
quite a few RFC's but in our experience has actually made it difficult
for our software to both comply with the RFC as well as Apple's client
software.
Hmm. Is that because Apple software doesn't conform, or the new RFCs
are cumbersome or overcomplicated?
CK
>>
>> Thank you Cedric.
:)
On 06/04/16 23:28, Cedric Knight wrote:
> The documentation for header_checks includes an example to "block
> attachments with bad file name extensions", and I expect many
> installations have a similar rule to cut down on malware. This reads:
>
> /^Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(
> ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|
> hlp|ht[at]|
> inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws|
> \{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}|
> ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf|
> vb[esx]?|vxd|ws[cfh]))(\?=)?"?\s*(;|$)/x
> REJECT Attachment name "$2" may not end with ".$4"
>
> Unfortunately, this can now block valid email from iPhone/iOS/ithing
> users. The second ".*" can span multiple parameters. This shows up in
> logs when searching for "x-apple-part-url" as follows:
>
> postfix/cleanup[1234]: 123412341234: reject: header Content-Type:
> application/vnd.ms-publisher;??name="redacted
> redacted.pub";??x-apple-part-url="abcd1234-1234-5678-9999-123412341...@yahoo.com"
>
> What Apple has done seems legal under RFC 2045 but may make some of
> their users' email undeliverable.
>
> Rules can be amended to limit to "token" or "quoted-string" versions of
> the filename like this:
>
> /^Content-(Disposition|Type).*name\s*=\s*
> ("(?:[^"]|\\")*|[^();:,\/<>\@\"?=<>\[\]\ ]*)
> ((?:\.|=2E)(
> ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|
> hlp|ht[at]|
> inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws|
> \{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}|
> ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf|
> vb[esx]?|vxd|ws[cfh])(\?=)?"?)\s*(;|$)/x
> REJECT Attachment name $2$3 may not end with ".$4"
>
> A separate security point is that this doesn't actually block "bad"
> extensions if the Content-Type name is base64 encoded and the filename
> parameter in the Content-Disposition is percent-encoded.
