Debian Bug report logs - #855696
amavisd-new: Filter javascript from base64 encoded html

version graph

Package: amavisd-new; Maintainer for amavisd-new is Brian May <[email protected]>; Source for amavisd-new is src:amavisd-new (PTS, buildd, popcon).

Reported by: herrmann <[email protected]>

Date: Tue, 21 Feb 2017 11:27:02 UTC

Severity: wishlist

Tags: upstream

Found in version amavisd-new/1:2.10.1-2~deb8u1

Reply or subscribe to this bug.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to [email protected], Brian May <[email protected]>:
Bug#855696; Package amavisd-new. (Tue, 21 Feb 2017 11:27:04 GMT) (full text, mbox, link).


Acknowledgement sent to herrmann <[email protected]>:
New Bug report received and forwarded. Copy sent to Brian May <[email protected]>. (Tue, 21 Feb 2017 11:27:04 GMT) (full text, mbox, link).


Message #5 received at [email protected] (full text, mbox, reply):

From: herrmann <[email protected]>
To: Debian Bug Tracking System <[email protected]>
Subject: amavisd-new: Filter javascript from base64 encoded html
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)



Information forwarded to [email protected]:
Bug#855696; Package amavisd-new. (Thu, 23 Feb 2017 06:06:02 GMT) (full text, mbox, link).


Acknowledgement sent to Brian May <[email protected]>:
Extra info received and forwarded to list. (Thu, 23 Feb 2017 06:06:02 GMT) (full text, mbox, link).


Message #10 received at [email protected] (full text, mbox, reply):

From: Brian May <[email protected]>
To: herrmann <[email protected]>, [email protected]
Subject: Re: Bug#855696: amavisd-new: Filter javascript from base64 encoded html
Date: Thu, 23 Feb 2017 17:02:06 +1100
herrmann <[email protected]> writes:

> 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.

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 protected]>



Information forwarded to [email protected], Brian May <[email protected]>:
Bug#855696; Package amavisd-new. (Thu, 23 Feb 2017 12:06:03 GMT) (full text, mbox, link).


Acknowledgement sent to Georg Herrmann <[email protected]>:
Extra info received and forwarded to list. Copy sent to Brian May <[email protected]>. (Thu, 23 Feb 2017 12:06:03 GMT) (full text, mbox, link).


Message #15 received at [email protected] (full text, mbox, reply):

From: Georg Herrmann <[email protected]>
To: <[email protected]>
Subject: Re: Bug#855696: amavisd-new: Filter javascript from base64 encoded html
Date: Thu, 23 Feb 2017 12:54:13 +0100
> Do the $banned_filename_re or $banned_namepath_re amavisd-new perl
> 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.

> 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.

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



Send a report that this bug log contains spam.


Debian bug tracking system administrator <[email protected]>. Last modified: Thu May 15 19:41:08 2025; Machine Name: bembo

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU General Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.