[Pkg-clamav-devel] Bug#840331: Bug#840331: clamav autoconfiguring a Proxy based on Apt settings

[Sebastian Andrzej Siewior]

On 2016-10-10 17:54:12 [+0100], T A F Thorne wrote:

> If I check in /etc/clamav/freshclam.conf I can see:
> # Check for new database 24 times a day
> Checks 24
> DatabaseMirror db.local.clamav.net
> DatabaseMirror database.clamav.net
> # Proxy: http://warden.pt.local:3142/
> HTTPProxyServer warden.pt.local
> HTTPProxyPort 3142
> 

> I believe that the automatic configuration of this package is behaving
> in the wrong way. It should not be selecting warden as a Proxy.

Correct. During the installation process of clamav-freshclam debconf
checks http_proxy and takes whatever is here and uses it as a http_proxy
for freshclam.

> Warden is set as a proxy for APT on my system. It has Apt-Cacher NG
> installed for this purpose. In my /etc area, warden is only mentioned in
> the /etc/apt/apt.conf.d/02proxy file and in the automatically generated
> /etc/clamav/freshclam.conf file.
> $ sudo rgrep warden.pt.local /etc/
> /etc/clamav/freshclam.conf:# Proxy: http://warden.pt.local:3142/
> /etc/clamav/freshclam.conf:HTTPProxyServer warden.pt.local
> /etc/apt/apt.conf.d/02proxy:Acquire::http { Proxy
> "http://warden.pt.local:3142"; };

can you do
	echo $http_proxy
	sudo echo $http_proxy

> When I check other machines on my network that have a similar setting
> for apt, they also express this error messages about clamav in their
> syslogs. As far as I can see both 14.04 and 16.04 machines exhibit the
> same behaviour.

this is like that since a _long_ time.

> I am willing to accept that I have mis-configured apt in some way to
> cause this. If that is likely, how should I setup an apt only http
> cache? I have not noticed any other program attempt to automatically use
> apt for all HTTP traffic.

The only way for freshclam to pickup a proxy is to have http_proxy
environtment variable set during the install process. From a grep
through apt's source I can't see that apt sets this variable. I see that
apt will use http_proxy if set but it won't set it by itself (if
configured as you did via the "Acquire::http" option).
That means I don't see anything wrong. I *assume* that you have (or had)
http_proxy set during the install process and now you ended up with it.
You can drop it by calling
	dpkg-reconfigure clamav-freshclam
and then it should not come back.

You could also use use
	deb http://warden.pt.local:3142/ubuntu

in your /etc/apt/sources file instead of setting the proxy on your box
_and_ the debian mirror. The advantage is that now everybody would use
the mirror configure in apt-proxy-ng. Otherwise apt-cacher-ng would keep
two copies of the same file if two different mirrors were used (I think
if I remember it correctly).

> Would this bug be a security vulnerability? If a large number of
> machines do not get av definition updates for months or years at a time
> I could see how that could compromise a system in some small way. I will
> avoid marking it as such for now as I am not sure it really is one.

Well. You should test your box after an installation. That is the first
point where it was not working. So it was not working at all. Second you
should monitor your boxes (as a good sysadmin) and have an eye on things
like that. It is also possible that the upstream blacklisted your ISP
for one reason or another _or_ that clamav made an update to its
database and you required a newer version to keep it working.
What I am trying to say is that it is hard hard to argue that "this is a
security vulnerability" while at the same time you admit that you did
not check log files for "for months or years".

> Certainly, here is what I can find on my system:
> thomasthorne at thorne-ul-dt:~$ echo $http_proxy

since you don't have this set here, is it possible that it was at the
installation time?

Sebastian