Banning .docm gives misleading error message

[Kai Risku]

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:



--- amavisd 5 Apr 2016 06:30:18 -0000 1.24

+++ amavisd 5 Apr 2016 06:30:29 -0000

@@ -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) {







--

***@arrak.fi GSM [phone]

Oy Arrak Software Ab http://www.arrak.fi

[Dino Edwards]

If you are trying to block office documents that will infect your PC with ransomware your approach will not work. The ransomware has been coming through with the old office document extensions. For example, the locky ransomware comes in with a .doc attachment. A more effective approach would be to block all old office extensions i.e. .xls, .doc etc.



From: amavis-users [mailto:amavis-users-bounces+dino.edwards=***@amavis.org] On Behalf Of Kai Risku
Sent: Tuesday, April 5, 2016 2:54 AM
To: amavis-***@amavis.org
Subject: Banning .docm gives misleading error message

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:

--- amavisd 5 Apr 2016 06:30:18 -0000 1.24
+++ amavisd 5 Apr 2016 06:30:29 -0000
@@ -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) {

[Kai Risku]

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.



--

***@arrak.fi GSM [phone]

Oy Arrak Software Ab http://www.arrak.fi



From: amavis-users [mailto:amavis-users-bounces+kai.risku=***@amavis.org] On Behalf Of Dino Edwards
Sent: Tuesday, April 05, 2016 11:04 AM
To: amavis-***@amavis.org
Subject: RE: Banning .docm gives misleading error message



If you are trying to block office documents that will infect your PC with ransomware your approach will not work. The ransomware has been coming through with the old office document extensions. For example, the locky ransomware comes in with a .doc attachment. A more effective approach would be to block all old office extensions i.e. .xls, .doc etc.







From: amavis-users [mailto:amavis-users-bounces+dino.edwards=***@amavis.org] On Behalf Of Kai Risku
Sent: Tuesday, April 5, 2016 2:54 AM
To: amavis-***@amavis.org
Subject: Banning .docm gives misleading error message



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:



--- amavisd 5 Apr 2016 06:30:18 -0000 1.24

+++ amavisd 5 Apr 2016 06:30:29 -0000

@@ -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) {







--

***@arrak.fi GSM [phone]

Oy Arrak Software Ab http://www.arrak.fi