Re: [squid-users] transparent squid + clamav + https

On Wed, Mar 17, 2010 at 03:53:01AM +0000, Amos Jeffries wrote:
>
> So HAVP is designed specifically to send client scanned parts of the file
> before the entire thing is checked?

Right. Of course all this is configurable.

> That explains something that I was wondering about...
>
> Consider this scenario which I have seen in the wild:
>
> Background: Clients visit website A and fetch a large document PDF file.
> Unknown to the website author the server has been infected and PDF is one
> of the files which get a macro virus appended. The CRM system records in a
> database the upload and change times for efficient if-modified responses.
> The server admin is alerted and runs a virus scan, cleaning the files some
> time later. The CRM database gets omitted from the update.
>
> Imagining that HAVP was in use in a proxy between this site and a user...
>
> During the infected period imaginary-HAVP scans the documents and sends a
> large "clean" prefix to all visitors.
> BUT... aborts when the appended infection is detected. Browser is lucky
> enough to notice the file is incomplete and retires later with a range
> request for the missing bit.
>
> a) during the infected period the fetched ranges will never succeed.

HAVP doesn't allow Range requests by default anyway, always forcing a full
download.

> b) after the infection is cleaned up the file will pass through
> imaginary-HAVP and client will get a truncated version. With complete-file
> being indicated.
>
> This is where the problem comes in. Being a macro infection one of the
> changes to the file was that the virus appended some undetectable jump code
> at the beginning to go with the virus at the end.
>
> We are left with the situation where intermediary proxies are holding
> corrupted files (first part being original infected with jump, followed by
> terminal bytes of teh file. the server is left with a pristine and working
> file. New visitors loading it will be fine, and sill analysts coming along
> later.
>
> However for clients visiting through one of the proxies which cached the
> file meanwhile ... One of two things will happen to depending on the file
> viewer used:
> 1) dumb viewer will try to run the random part of file (now text!) where
> virus inserted itself as binary code and crash.
> 2) smart viewer will notice the missing/corrupt macro (its past the end
> of file maybe) and display the file without running it. However, even then
> there is a discrepancy in file prefix and some of the content appears
> corrupted.
>
> This type of traffic is the #1 reason for buffering until fully processed.
> I do like the idea of incremental scanning as it arrives though. That will
> at least reduce the delays to very little more than the total receiving
> time.

The recommended configuration is not to cache between client and HAVP. It
comes at a small penalty of scanning files every time, but also has a bonus
of detecting viruses that are in cache but hadn't signatures at that time.

http://havp.hege.li/forum/viewtopic.php?f=2&t=11

So I'm not sure your worries apply.. please clarify if I didn't understand.
Received on Wed Mar 17 2010 - 04:16:49 MDT