HTTP Anti-Virus Proxy

Hi
I have an issue with my havp 0.86 implementation on FreeBSD 6.2, using as a scanner f-prot 4.6.8.

When i try to download some .gz files i have a "could be an archive bomb error". An example of one of those is ftp://ftp.ncbi.nih.gov/pub/geo/DATA/sup ... 316.cel.gz

The strange thing is that if i download the file and run the antivirus locally on it everything goes fine, so this must not be an issue that is stricly related to f-prot, but more of an havp issue.

I must point that on FreeBSD there is no mandatory lock enabled PS available,but i do not think the issue is related to this.

Have someone had a problem like this? what can be the cause and eventually the solution?

It is up to your f-prot configuration, what it considers as an "archive bomb", nothing to do with HAVP. So see if there are any recursion/max etc settings in f-prot.conf.

You can also try the new IGNOREVIRUS config, if you can't solve it otherwise.

Yes, but seing that running f-prot on those file do not produce that error i thought that it must have something to do with the way HAVP pass the file to scan to the scanners (this error is produced when f-prot find the archive "difficult" to scan for some reason: recursive archiving, excessive compress ratio and so on)

To pass the file exactly like HAVP, you can do this:

telnet localhost fprotport

GET /path/to/file HTTP/1.0<enter>
<enter>

Nothing else is sent. I don't have f-prot installed, so I can't test anything more. You can try using truss/strace to see what the f-prot client sends to the daemon and if it's different.

I did your test, and tried to pass via GET the file to fprot. The results are :

passing the file this way (downloading it, telnetting to fprot port and issuing a GET) reports a clean file.
Then i tried to tcpdump the fprot port while trying to download the file via browser and i saw that when is the HAVP temporary file to be passed, the result is the "archive bomb" stuff.

So my conclusion is that maybe the temporary files themself are not clean, that something happen in the moment the downloaded file become the HAVP temporary file that is passed to the scanners. If it would be exactly the same as the file being downloaded passing it to the scanner would give exactly the same result....

What could i do to further investigate the issue? I could even have met a rare HAVP bug, so knowing better what's happening is importanto to the community too, not only to me

To clarify more:

This is the file passed with a GET:

root@squid:~ telnet 127.0.0.1 10200
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /root/gsm65316.cel.gz HTTP/1.0

HTTP/1.0 200 Ok
Server: fprotd/4.6.8
Date: Mon, 02 Jul 2007 09:31:07 GMT
Content-Type: text/plain

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE fprot-results [
<!ELEMENT fprot-results (arguments+, error?, filename+, detected*, summary)>
<!ATTLIST fprot-results
version
CDATA
#REQUIRED

engine
CDATA
#REQUIRED

program
CDATA
#REQUIRED
>
<!ELEMENT arg (#PCDATA)*>
<!ELEMENT error (#PCDATA)*>
<!ELEMENT arguments (arg*)>
<!ELEMENT filename (#PCDATA)*>
<!ELEMENT summary (#PCDATA)>
<!ATTLIST summary
code
CDATA
#REQUIRED
>
<!ELEMENT name (#PCDATA)*>
<!ELEMENT accuracy (#PCDATA)*>
<!ELEMENT disinfectable (#PCDATA)*>
<!ELEMENT unknown (#PCDATA)*>
<!ELEMENT damaged (#PCDATA)*>
<!ELEMENT encrypted (#PCDATA)*>
<!ELEMENT unsupported (#PCDATA)*>
<!ELEMENT bad-file (#PCDATA)*>
<!ELEMENT bad-program (#PCDATA)*>
<!ELEMENT not-scanned (#PCDATA)*>
<!ELEMENT unrecognized (#PCDATA)*>
<!ELEMENT max-recursion-reached (#PCDATA)*>
<!ELEMENT encrypted-executable (#PCDATA)*>
<!ELEMENT disinfection (#PCDATA)*>
<!ATTLIST disinfection
code
CDATA
#REQUIRED
>
<!ELEMENT detected (name?, accuracy?, disinfectable?, disinfection?)>
<!ATTLIST detected
type
CDATA
#REQUIRED
>
]>
<fprot-results version="1.0" engine="3.16.16" program="4.6.8">
<arguments>
</arguments>
<filename>/root/gsm65316.cel.gz</filename>
<filename>/root/gsm65316.cel.gz-&gt;gsm65316.cel</filename>
<summary code="6">clean</summary>
</fprot-results>


This is the tcpdump of the fprot port while downloading the same file:

<!DOCTYPE fprot-results [
<!ELEMENT fprot-results (arguments+, error?, filename+, detected*, summary)>
<!ATTLIST fprot-results
version
CDATA
#REQUIRED

engine
CDATA
#REQUIRED

program
CDATA
#REQUIRED
>
<!ELEMENT arg (#PCDATA)*>
<!ELEMENT error (#PCDATA)*>
<!ELEMENT arguments (arg*)>
<!ELEMENT filename (#PCDATA)*>
<!ELEMENT summary (#PCDATA)>
<!ATTLIST summary
code
CDATA
#REQUIRED
>
<!ELEMENT name (#PCDATA)*>
<!ELEMENT accuracy (#PCDATA)*>
<!ELEMENT disinfectable (#PCDATA)*>
<!ELEMENT unknown (#PCDATA)*>
<!ELEMENT damaged (#PCDATA)*>
<!ELEMENT encrypted (#PCDATA)*>
<!ELEMENT unsupported (#PCDATA)*>
<!ELEMENT bad-file (#PCDATA)*>
<!ELEMENT bad-program (#PCDATA)*>
<!ELEMENT not-scanned (#PCDATA)*>
<!ELEMENT unrecognized (#PCDATA)*>
<!ELEMENT max-recursion-reached (#PCDATA)*>
<!ELEMENT encrypted-executable (#PCDATA)*>
<!ELEMENT disinfection (#PCDATA)*>
<!ATTLIST disinfection
code
CDATA
#REQUIRED
>
<!ELEMENT detected (name?, accuracy?, disinfectable?, disinfection?)>
<!ATTLIST detected
type
CDATA
#REQUIRED
>
]>
<fprot-results version="1.0" engine="3.16.16" program="4.6.8">
<arguments>
</arguments>
<filename>/var/tmp/havp/havp-o18QiL</filename>
<detected type="special">
<message num="129"> could be an archive bomb</message>
<accuracy>0</accuracy>
<disinfectable>no</disinfectable>
</detected>
/var/tmp/havp/hav

Is your MAXSCANSIZE bigger or smaller than the archive? Can you see a difference if you change it the other way?

I would guess you have it set smaller, so the scanner only sees part of the file. It could cause the problem.

You got it...almost

My MAXSCANSIZE was quite low for performance reasons; i raised it to 10.000.000 (that is 10 Mb right?) and now i am able to download a 300 Mb gz archive without the archive bomb error. But frankly i cannot imagine why (i can speculate that with my previous 200k limit the portion of the file being scanned was not complete enough to let fprot consider it a valid archive, but i can not be sure about this)

I am glad you helped me solving the issue but i wanted to inform you of this weirdness

Regards

Yeah 200k is maybe unnecessarily low, shouldn't make much difference to raise it to a few MB. There could be viruses/trojans bigger than 200k, so it's safer too.