# amavisd-new && virus that gets through

## BlinkEye

i just found this great site: http://www.testvirus.org/ and tested my mailserver. unfortunately 3 viruses get through:

```

Test #19: Eicar virus within zip file hidden using the "Blank Folding Vulnerability"

  

Test #24: Test for the "Partial (Fragmented) Vulnerability". This does not include Eicar virus, but your mail server still must block this since it can break a virus into multiple emails and reassemble it in your inbox.

Test #25: Attachment with a CLSID extension which may hide the real file extension. This does not include Eicar virus, but your mail server still must block this since it can hide the true extension of a file.

```

any idea on how to configure clamav that these mails get quarantined?

----------

## Little Nemo

clamav is not perfect. I am using two more virus scanners (f-prot and H&BEDV antivir) in an amavisd-new setup to scan for viruses, and each of them fails to detect certain viruses. Redundancy therefore is a good idea.

----------

## BlinkEye

yeah, that's what i thought. have you ever tried the site mentioned above (i.e. get all viruses recognized)?

----------

## Little Nemo

 *BlinkEye wrote:*   

> yeah, that's what i thought. have you ever tried the site mentioned above (i.e. get all viruses recognized)?

 

I just did. Here's the result:

Only antivir passed test 8 (Eicar virus sent using BinHex encoding within a MIME segment).

Only f-prot passed test 19 (Eicar virus within zip file hidden using the "Blank Folding Vulnerability").

Test 23 (Eicar virus within zip file hidden using the "Empty MIME Boundary Vulnerability") was sorted out by amavisd because of a "banned name", so none of the scanners got to examine it.

None of the scanners passed tests 12 (Eicar virus within a password protected ZIP file) and 25 (attachment with a CLSID extension).

All scanners passed all other tests.

The results are irritating because in fact all scanners do recognize the Eicar virus and amavisd-new should take care of ripping the mail apart and isolating its parts. It obviously does a bad job with tests 8 and 19 (but antivir respectively f-prot still recognize the mail as infected). The amavisd-new message for test 23 is misleading, but at least the mail does not reach its recipient. Test 12 is a tough one, I'll see whether I can modify amavisd-new to ban password-protected zip files altogether. Test number 25 is another issue that needs to be looked into.

In fact for me this was more of an amavisd-new test than one of the mail scanners. The way it should work is that amavisd isolates all parts of an email and has the scanners scan each part. As this may not always work, the complete mail body is scanned again (this is how antivir must have passed test 8 and f-prot passed test 19, I reckon).

I am using amavisd-new 20030616. Is there really no newer version available?

[edit]Test #24 is actually another case where amavisd-new does its job well (see test #23). It recognized a partial mail and blocked the mail, so none of the scanners got to see it.[/edit]Last edited by Little Nemo on Sun May 23, 2004 3:29 pm; edited 1 time in total

----------

## BlinkEye

thanks for the detailed answer. i use the same version as you do - but there would be a masked newer version:

```
emerge -pv /usr/portage/net-mail/amavisd-new/amavisd-new-20030616_p9.ebuild

```

from http://www.ijs.si/software/amavisd/:

 *Quote:*   

> amavisd-new-20030616-p9.tar.gz (md5 sum) 
> 
> the latest version of amavisd-new, considered stable and suitable for general deployment; 
> 
> The P9 fixes few minor problems that P8 introduced, adds more workarounds for Perl taint bugs, recognizes SFX LHA archives, supports DrWebD 4.31, The helper program amavis-milter.c now checks and properly reports the status of all calls to mkdir/rmdir/open/unlink/write, and makes a clear distinction between message data and connection data. Please see the RELEASE NOTES. Patch files are available for reference, they do not include documentation changes: p9, p8, p7, p6, p5, p4A, p4B, p3, p2, p1. 
> ...

 

please keep me up to date if you figure out how to configure amavisd-new properly (maybe a mail to the developer would be a good idea?).

you say you're using antivir, is that the antivir from H+BEDV? if yes which version do you use (mailgate or the normal version)? i used antivir for a workstation once and it was quite hard to build the dazuko module which is needed for antivir (well, the problem was that i used some 2.6.0-test-xx kernel then). have you achieved that all by yourself or have you found a howto?

----------

## BlinkEye

btw: i passed test 8 and 12:

test 12:

 *Quote:*   

> Two viruses (Encrypted.Zip, Encrypted.Zip) were found.
> 
> Scanner detecting a virus: Clam Antivirus-clamd
> 
> The mail originated from: <?@crc2.excedent.us>
> ...

 

test 8:

 *Quote:*   

> A virus (Eicar-Test-Signature) was found.
> 
> Scanner detecting a virus: Clam Antivirus-clamd
> 
> The mail originated from: <tester@testvirus.org>
> ...

 

----------

## Little Nemo

Yes, I'm using H+BEDV antivir. It is the standalone scanner which is recognized by amavisd-new automatically. F-prot is also the standalone version. Having amavisd-new handling the mail structure and forwarding its parts to the scanners seemed a better solution than using each vendor's own mailgate mechanism.

I have incorporated amavisd-new into my exim setup. Mails are passed to the SMTP interface of amavisd-new, examined and handed back to exim on another TCP port. No mail is really accepted by amavisd-new until is is re-delivered and accepted by exim, so there is no danger of losing mail through a hypothetical amavisd-new malfunction.

I don't know of a HOWTO, I only read the docs. If there is interest in how to set this up, I might write a small HOWTO (although this is running on a Debian machine, not Gentoo).

----------

## Little Nemo

 *BlinkEye wrote:*   

> btw: i passed test 8 and 12:
> 
> 

 

Then your amavisd-new must be newer than mine (still using version p7). I'll upgrade and try again. [edit]That leaves tests #19 and #25 to be dealt with[/edit]

[edit]Off-topic: p7 is the newest available debian package, there's not .deb file for p9. This has been filed as a "wishlist" bug 40 days ago which was later promoted to "important", but nothing has happened since. I guess there are reasons for turning away from Debian as I did for my desktop machines.[/edit]

----------

## BlinkEye

update - i installed the -p9 version and now #12,#19,#24,#25 get through. not really a better behaviour   :Crying or Very sad: 

----------

## Little Nemo

 *BlinkEye wrote:*   

> 
> 
> ```
> 
> Test #24: Test for the "Partial (Fragmented) Vulnerability". This does not include Eicar virus, but your mail server still must block this since it can break a virus into multiple emails and reassemble it in your inbox.
> ...

 

Did you uncomment this line in your amavisd-new configuration file?:

```
qr'^message/partial$'i, qr'^message/external-body$'i, # rfc2046

```

----------

## BlinkEye

nope. you're good, thanks a lot

----------

## MarkG

 *Little Nemo wrote:*   

> 
> 
> Did you uncomment this line in your amavisd-new configuration file?:
> 
> ```
> ...

 

Thanks for the Tip, just 19 and 25 to fix now!

MarkG

----------

## Little Nemo

 *MarkG wrote:*   

> Thanks for the Tip, just 19 and 25 to fix now!
> 
> 

 

#19 is not handled by amavisd-new, although it would be easy to do so. amavisd-new should block any mail containing a single space or tab in the header.

When fed a mail like that (an infected zip file hidden in the headers), f-prot still recognizes the virus. antivir and clamav don't.

#25 is not handled by amavisd-new either. Should be easy to fix, too. I'll try to find out whether there already is a bug report. If not, I'll file one.

----------

## BlinkEye

 *MarkG wrote:*   

> Thanks for the Tip, just 19 and 25 to fix now!MarkG

 

are you sure you passed #12? i don't pass that one with the newest version (p9), even though i have now clamav, antivir and f-prot installed

----------

## MarkG

 *BlinkEye wrote:*   

> 
> 
> are you sure you passed #12? i don't pass that one with the newest version (p9), even though i have now clamav, antivir and f-prot installed

 

Well it didn't fail, as its a password protected zip file amavisd-new passed it on but the subject line was tagged with ***UNCHECKED***, I think that counts as detecting a threat. I'm also using amavis-new version 20030616_p9, but currently only have clamav installed since I only started setting it up yesterday.

As a matter of interest what policy have people adopted as far as informing the originator. I notice from my mail logs that I am sending a message to tester@testvirus.org after each message is blocked. There is a discussion on the merits of informing/ not informing the originator in the amavis-new documentation README.policy-on-notifications, but I'm not sure which way to go. It's not a problem at the moment as I don't have a virus problem.

MarkG

----------

## BlinkEye

 *MarkG wrote:*   

> As a matter of interest what policy have people adopted as far as informing the originator. I notice from my mail logs that I am sending a message to tester@testvirus.org after each message is blocked. There is a discussion on the merits of informing/ not informing the originator in the amavis-new documentation README.policy-on-notifications, but I'm not sure which way to go. It's not a problem at the moment as I don't have a virus problem.MarkG

 

i don't think i'm following you

----------

## MarkG

 *BlinkEye wrote:*   

> i don't think i'm following you

 

OK, I'll try and make more sense. There are basically two cams on the policy for discarding infected mail:

1) The "lose no mail" who believe mail server should not lose mail, to drop mail without telling the originator is unforgivable as it create a mail black hole. 

2) The "acceptable losses" cam who believe there is no point in informing the originator that they sent a virus as its was probably sent intentionally, from a faked address in the first place. Bouncing the virus back the the faked originating address is the worst thing to do as it just proppergates the virus to yet another machine.

The default settings with amavis-new bounce a message (not including the virus) back to originator, but the discussion in the README.policy-on-notifications suggests that this is not the thing to do. Any thoughts?

MarkG

----------

## Little Nemo

 *MarkG wrote:*   

> The "acceptable losses" cam who believe there is no point in informing the originator that they sent a virus as its was probably sent intentionally, from a faked address in the first place. Bouncing the virus back the the faked originating address is the worst thing to do as it just proppergates the virus to yet another machine.
> 
> 

 

amavisd-new does no propagate the virus to another machine when informing the sender.

Of course you might have configured your MTA to return the original mail to the sender when amavisd-new reports a virus, but that would be a misconfiguration of your MTA. If you really want to inform the sender, then the MTA should drop the infected mail and leave it to amavisd-new to send a notification.

As almost all of the viruses currently caught by our mailgate come with faked sender addresses, neither behaviour makes sense, though. I'm simply quaranting the mail, informing the recipient and not sending notification to the sender. In most cases it will be sent to the wrong person.

I'm receiving dozens of "your mail to xyz was infected with a virus" reports daily. All they tell me is that my address is being used as a fake sender address. For me that's okay. Most people don't know anything about this, though, and they'll be alarmed for no reason.

----------

## mallchin

Passed all 26 tests here  :Razz: 

----------

## BlinkEye

hmm, test mail #25 still gets through ...  :Question: 

----------

## mallchin

Seems some got delayed, I've just noticed #'s 24 & 25 made it through  although I think I'll allow these. 

#24 is a test for fragmented files, amavis passed it for virus/spam and successfully detected it as a multi-part message. I am sure this might allow for vunerabilities under Outlook but Evolution doesn't seem to mind:

```

Subject: Virus Scanner Test #24 (non-virus)

Mime-Version: 1.0

Content-Type: message/partial; total=2; id=partialmsg; number=1

Content-Transfer-Encoding: 7bit

```

#25 also allows for some Outlook vunerabilities which don't affect evolution. The attachment was successfully discovered and displayed as a text file, not a wav, and therefore isn't a threat:

```

         Plain text document attachment (clsidfile.txt.{00020C01-0000-0000-C000-000000000046})

```

I have other installations running Outlook however and these might cause concern there, hrm...

----------

