Filetype Checks: No executables on Greek Emails
Nikolaos Pavlidis
Nikolaos.Pavlidis at beds.ac.uk
Mon Apr 8 11:06:05 IST 2013
Hello all,
So this should remain ClamAV Full Message Scan = yes ?
Find UU-Encoded Files is set to “no” though
Kind regards,
Nik
From: Steen, Glenn [mailto:Glenn.Steen at ap1.se]
Sent: 08 April 2013 09:47
To: Nikolaos Pavlidis
Cc: mailscanner at lists.mailscanner.info
Subject: RE: Filetype Checks: No executables on Greek Emails
fre 2013-04-05 klockan 14:37 +0000 skrev Nikolaos Pavlidis:
Hello all,
Many thanks Glenn for the very detailed explanation! I have made the changes and I am holding my breath to see what happens.. after all.. I cannot test it with the email that is in the quarantine.. it is already buggered! Many thanks for all your help.
Final question:
Is disabling that option going to affect the http://www.inetmsg.com/pub/ unofficial signature databases I am using with ClamAV?
Thanks again.
Kind regards,
Nik
Sorry Nik (and Steve!)... I think I'm turning slightly senile:-)... Steve is right, that option is to dump the entire message *with headers* in there, which is likely harmless to the file command(s)... What I was thinking of, but remembering kind of wrong, was the
Find UU-Encoded Files =
setting ... If that one is "yes", change it to "no".
Cheers
--
-- Glenn
From: mailscanner-bounces at lists.mailscanner.info<mailto:mailscanner-bounces at lists.mailscanner.info> [mailto:mailscanner-bounces at lists.mailscanner.info] On Behalf Of Glenn Steen
Sent: 05 April 2013 10:11
To: MailScanner discussion
Subject: Re: Filetype Checks: No executables on Greek Emails
BTW, when stripping down the body, you may need "de-MIME" a bit as well, to get the actual thing that file sees... Can be a bit tricky:-).
IIRC there is a common greek greeting phrase that will start with a character that is guaranteed to be interpreted as a DOS executable... so you might not need go through the trouble of the copy/edit thing, just put that greeting in a (text) file and run file/file -i on that... or just cut'n'paste from your MUA, or similar.
I mentioned russion and greek specifically, but this has been reported for other non-english languages as well (french and some south east asian language, at least... for french the culprit was an É or Ë or similar).
Cheers!
--
-- Glenn
On 5 April 2013 10:54, Glenn Steen <glenn.steen at gmail.com<mailto:glenn.steen at gmail.com>> wrote:
I'm guessing that you have
ClamAV Full Message Scan = yes
set in MailScanner.conf ... This will make MailScanner "unpack" the body of the email as a file in the directory presented to ClamAV for scanning (other AVs don't seem to need this "help"). The goal is to catch malware that isn't "properly" encoded, but rather just dumped in the message body.
For non-english locales, especially greek and russian locales, this can be ... less than fortunate, since the "body file" will be present when the file command is run on the directory, and the file command has some very naive one byte magic detection "strings" that will interprete common greek (or russion KOI-8) characters as being the start of an MS-DOS executable (COM-files et al).
When the message is quarantined, the "whole message file" (including headers) is stored in the quarantine (not the file containing just the body), so a simplistic "file message" command will not show the root cause. You need make a copy of that file and manually remove all the headers (and the blank line separating the headers from the body), then run file (and file -i) command on that to see the gory details:).
Provided one has the file -i column in filetypes.rules.conf (it is an optional fifth column, meaning that you likely don't have it and need add it yourself... The columns are <TAB> -separated!), you can use the file -i commands "findings" in that column, for the line that triggers the blocking.... Having lines with file -i "syntax" will make the file -i take precedence ... I think, at least.
The common practice of changing the "File Command = " setting to the file -i command is perhaps less work, but it is also less secure, since the string matching on the result may be even less reliable than usual. Then again, file type checking is more of an art than a science:-):-).
As I'm sure you've noticed, this isn't a new problem, it has been with MailScanner for quite a few years (if not since the very begining). The methods for fixing the problem has varied over the years (editing the magic file, reporting it to the file command maintainers as a bug, using file -i straight up etc), but the interface Jules has provided is actually the very best imaginable, so do explore that... In a stock filetype.rules.conf file there is even an example for the DOS executables that file -i might find (hopefully a bit more securely than the plain file command... Though the commands are actually one and the same, the -i uses a different magic file, not just different descriptive strings).
Changing the ClamAV setting shown above to "no" will make this problem a lot less common (read: go away completely:-), as well, so that might be another very viable option... If you use more than one AV, you don't lose that much security by doing so.
Cheers!
--
-- Glenn
Den 22 mar 2013 16:40 skrev "Nikolaos Pavlidis" <Nikolaos.Pavlidis at beds.ac.uk<mailto:Nikolaos.Pavlidis at beds.ac.uk>>:
Hello all,
I'm having an issue with Mailscanner which weirdly enough has been already discussed here
http://markmail.org/message/56fofuvh4tzde7hz#query:+page:1+mid:mu77m5qs6zjhh2jx+state:results
The problem is:
Mar 22 15:00:18 smtp1 MailScanner[17935]: Filetype Checks: No executables (r2JAPluH011324 )
Mar 22 15:00:46 smtp1 MailScanner[17935]: Saved entire message to /var/spool/MailScanner/quarantine/20130322/r2JAPluH011324
And:
[root at smtp1 r2JAPluH011324]# pwd
/var/spool/MailScanner/quarantine/20130322/r2JAPluH011324
[root at smtp1 r2JAPluH011324]# ll
total 28K
-rw------- 1 root root 22K Mar 22 15:00 dfr2JAPluH011324
-rw------- 1 root root 3.7K Mar 22 15:00 qfr2JAPluH011324
[root at smtp1 r2JAPluH011324]# file -i *
dfr2JAPluH011324: text/plain; charset=us-ascii
qfr2JAPluH011324: text/plain; charset=unknown
But I have also added the lines suggested in the previous thread so my filetype.rules.conf looks like:
<snip>
allow text - -
allow - text/plain - -
allow - text/x-mail - -
allow - message/rfc822 - -
allow \bscript - -
allow archive - -
allow postscript - -
deny self-extract No self-extracting archives No self-extracting archives allowed
deny executable No executables No programs allowed
<snip>
I have restarted mailscanner before re-queuing the message but always the same result...
Any ideas/recommendations would be much appreciated,
Kind regards,
Nik
--
MailScanner mailing list
mailscanner at lists.mailscanner.info<mailto:mailscanner at lists.mailscanner.info>
http://lists.mailscanner.info/mailman/listinfo/mailscanner
Before posting, read http://wiki.mailscanner.info/posting
Support MailScanner development - buy the book off the website!
--
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mailscanner.info/pipermail/mailscanner/attachments/20130408/dab7cb58/attachment.html
More information about the MailScanner
mailing list