Subject: amavisd-new: Filter javascript from base64 encoded html

From: herrmann <[email-masked]>
Date: Tue, 21 Feb 2017 12:13:32 +0100

Package: amavisd-new
Version: 1:2.10.1-2~deb8u1
Severity: wishlist
Tags: upstream

I'm used to filter mails which contain javascript or other kinds of directly
executable scripts. This is simply done with some regex's in postfix
body_checks. But since some time javascript-trojans will increasingly be send
as base64 encoded html attachment, and in this case my approach to block them
via simple textanalysis fails.

With amavis I can quarantine javascript attachments (.js), I can quarantine
zipped attachments containing .js files - but I can't see no way, how to
quarantine attachments, which - after base64-decoding - contain script as pure
text.

If an attachment in it's very nature is a common text file, postfix seems to be
the first place to do some regex filtering on it. But I guess, it's beyond
postfix's scope to recognize and decode such attachments before regexing. So it
would be great, if them could be filtered with either amavis or with an amavis
plugin.

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (700, 'stable'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

---

From: Brian May <[email-masked]>
Date: Thu, 23 Feb 2017 17:02:06 +1100

> would be great, if them could be filtered with either amavis or with an amavis

Sorry, I am not 100% certain I understand what you want.

Do the $banned_filename_re or $banned_namepath_re amavisd-new perl
settings do what you want?

FYI: You might be better off asking on the amavisd-new user mailing
list, as I get the impression this is a help/support request, not a bug
report.

https://lists.amavis.org/cgi-bin/mailman/listinfo/amavis-users
-- 
Brian May <[email-masked]>

---

From: Georg Herrmann <[email-masked]>
Date: Thu, 23 Feb 2017 12:54:13 +0100

> settings do what you want?

No, absolutely not! These tags allow me to block files with e. g .a certain
extension. A file with extension .js probably contains javascript,
and javascript in an email can be considered malicious in almost any case. So
I will use $banned_filename_re to block such attachments.

But .html  can't be considered malicious or even dangerous by it's very
nature. In an email, html in almost any case contains harmless text. But
html can (and will increasingly) contain malicious javascript code. So if a
mail has an html-attachment, I must parse this attachment for keywords
like re(/meta content=3Djavascript/) and if an attachment contains such a
keyword, I will reject the mail with an appropriate error code.

That can be done in postfix. _As long_, as the attachment is text-encoded
(quoted-printable). But if the html-attachment is encoded base64, such simple
checks on postfix will fail. Now it is a job for amavis!

At least, it should be a job for amavis. But as far as I can see, there is no
integrated mechanism in amavis, to filter such content. Of course, malicious
code _could_ be detected by a virus scanner. But honestly, when in the past
few years have you ever seen a virus scanner discovering a zero day trojan?

Javascript in a html-attachment in an email shouldn't be a big threat, if
your mail client is configured to reject the execution of any script. But
what, if you read your mail in a web interface, in a browser? A browser in
almost any case will execute that script!

So a mailserver should either reject this kind of stuff, or at least mark it
as potentially dangerous. The latter can be done in amavis even today, if I
abuse amavis' virus scanner interface to call my own script, which decodes a
given attachment and parses it for certain keywords.

But I think, that it would be a much better solution, if amavis byself would
decode any base64 encoded attachment, which by it's filename resp. by it's
Content-Type can be considered to be a textfile (which can contain malicious
executable code) and if amavis would than parse this textfile for certain
keywords.

> list, as I get the impression this is a help/support request, not a bug

Your are right, it's not exactly a bug report. It's a feature request, thatfor
I filed this report with severity 'wishlist'. 

Regards
Georg