Banning .docm gives misleading error message
Mark Martinec
Mark.Martinec+amavis at ijs.si
Tue Apr 26 17:21:41 CEST 2016
On 2016-04-05 10:21, Kai Risku wrote:
> We also have ClamAV blocking all files containing OLE2 Macros, so I am
> going for a belt-and-suspenders type of approach…
>
> Regardless of the effectivity of blocking certain types of files or
> not, my main point for posting was the inability of amavis to clearly
> report which file was blocked when the blocked file is being detected
> as a container (e.g. a zip-file) containing other files.
[...]
> In order to guard against malicious macros, we have banned all
> macro-enabled Office document formats, i.e. added the following to
> $banned_filename_re:
>
> # block macro-enabled office files
> qr'.\.(xlsm|xltm|xlam|docm|dotm|pptm|potm|ppam|ppsm|sldm)$'i,
>
> Since modern Office documents are technically zip-files, amavisd-new
> opens and processes the zip archive. For originating (outgoing)
> messages we bounce the banned emails so the poor sender can understand
> why his emails are not delivered, but in this case amavisd-new does
> not report the actual office document being banned but instead blames
> the first file inside the zip-archive. This results in very cryptic
> error messages, like:
>
> Subject: BANNED contents from you
> (.txt,[Content_Types].xml)
>
> Our content checker found
> banned name: .txt,[Content_Types].xml
> in email presumable from you
>
> It seems amavisd has a small “optimization” that skips banned checks
> for non-leaf nodes. I propose removing that so the actual office
> documents can be directly banned and correctly reported:
>
> @@ -9912,7 +9912,9 @@
> my(@path) = @{$part->path};
> next if @path <= 1;
> shift(@path); # ignore place-holder root node
> - next if @{$part->children}; # ignore non-leaf nodes
> + # also process non-leaf nodes or we cannot block office
> documents
> + # without alert about wrong parts (blames the innocent zip
> member)
> + # next if @{$part->children}; # ignore non-leaf nodes
> my(@descr_trad); # a part path: list of predecessors of a
> message part
> my(@descr); # same, but in form suitable for check on
> banned_namepath_re
> for my $p (@path) {
I don't think the solution is not to ignore non-leaf nodes.
The non-leaf nodes information will be visible and checked
during processing of each leaf node - as their parent nodes.
This provides more information to checker, putting each
leaf node in its context.
The issue here is reporting, not checking. The %F macro
expands to whatever a method banning_reason_short() povides.
Perhaps this method should enhanced, or the notification
template should use more informative macros instead of %F
(in $notify_sender_templ ) :
BANNED contents from you (%F)
The following macros are available (README.customize) :
(or a new macro could be devised)
banning_rule_key a lookup key (a regexp) of a banning rule which
matched,
e.g.: (?-xism:^\\.(exe-ms|dll)$(?# rule #9))
banning_rule_comment a comment from a regexp in banning_rule_key, or
the whole banning_rule_key if it does not contain a
comment,
e.g.: rule #9
banning_rule_rhs right-hand side of a banning rule which matched,
often
just a '1', but can be any string which evaluates to
true
banned_parts a list of banned parts, with their full path in a
MIME/archive
e.g.: multipart/mixed |
application/octet-stream,.exe,.exe-ms,videos.exe
banned_parts_as_attr similar to banned_parts, but uses a different
syntax
using attribute/value pairs; currently known attributes
are:
P: part's base name, i.e. a file name in a ./parts/ temporary
directory
L: part's location (path) in a mail tree
M: MIME type as declared in MIME header fields of a message
T: short part's content type according to a file(1) utility
N: declared part names (none, one or more), as declared in MIME
header
fields or in an archive (tar, zip, ...)
A: part's attributes as follows:
U=undecodable, C=crypted, D=directory, S=special(device), L=link
e.g.:
P=p003,L=1,M=multipart/mixed |
P=p002,L=1/2,M=application/octet-stream,T=rar,N=Setup1.1.rar |
P=p007,L=1/2/4,T=exe,T=exe-ms,N=setup.exe
F just the first leaf node from banned_parts, with a prepended rule
comment
(if any), e.g.: rule
#9:application/octet-stream,.exe,.exe-ms,videos.exe
Mark
More information about the amavis-users
mailing list