Bug 13785 - privoxy, possible issues with reloading the service when needed
Summary: privoxy, possible issues with reloading the service when needed
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 4
Hardware: i586 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/606072/
Whiteboard: MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64...
Keywords: validated_update
Depends on:
Reported: 2014-07-22 17:19 CEST by David Walser
Modified: 2014-11-21 19:04 CET (History)
5 users (show)

See Also:
Source RPM: privoxy-3.0.21-2.mga4.src.rpm
Status comment:


Description David Walser 2014-07-22 17:19:33 CEST
OpenSuSE has issued an advisory on July 21:

It's not actually clear what the "security" issue is.

What I do see in their changes for this update:
- their logrotate config used the init script, which no longer exists
- they fixed it to call reload for the service
- they added something to the systemd service to support a reload call
- they added something for NetworkManager to reload the service on interface change

So, our logrotate config uses the service command, which should be fine.  However, I'm not entirely sure off the top of my head how systemd handles the reload call when the ExecReload is not specified (which it isn't in ours either), so maybe we should add that like OpenSuSE did.

I'm not sure why their NM thing is a "patch" when all it does is add a new file in /etc/NetworkManager/dispatcher.d/, but anyway, maybe we should add such a config too.

You can see their sources for the OpenSuSE 13.1 package here:

If you click the "Files changed" link at the bottom, you can see what they changed/added in this update.


Steps to Reproduce:
David Walser 2014-07-22 17:19:39 CEST

Whiteboard: (none) => MGA4TOO, MGA3TOO

Comment 1 Christiaan Welvaart 2014-10-25 17:02:37 CEST
Wonderful this is indeed broken in cauldron, I guess it wasn't a bad idea to move packages I maintain (sendmail) 100% to systemd.

CC: (none) => cjw
Assignee: cooker => cjw

Comment 2 Christiaan Welvaart 2014-10-25 17:08:30 CEST
Nope I used a very old privoxy, guess I should now fix issues I had in the new version.

Resolution: (none) => INVALID

Comment 3 David Walser 2014-10-25 17:16:25 CEST
So we don't need an ExecReload or a NM config?
Comment 4 Christiaan Welvaart 2014-10-25 19:23:00 CEST
Oops the current package does have this problem.

I tried to add ExecReload but privoxy still uses the old config file. So logrotate will have to restart the daemon instead.

Resolution: INVALID => (none)

Comment 5 Christiaan Welvaart 2014-10-25 19:25:20 CEST
I don't know anything about NetworkManager, don't use it so can't test anything related to this. How would something NM-related be a security issue? The issue with logrotate is that privoxy logs are not rotated, possibly filling the disk.
Comment 6 Christiaan Welvaart 2014-10-25 20:01:45 CEST
Proposed procedure:

1. install privoxy
2. start it (apparently not done on package install):
   systemctl start privoxy.service
3. set your favorite browser to use this proxy
   host: localhost  port: 8118
   Some browsers can be configured with an env var when started from the command line:  export http_proxy=localhost:8118
4. browse to a non-existent host, e.g. http://www.n.zz/

You should see a privoxy page saying "No such domain".

5. browse to one or two web sites to check that the proxy works properly

The logrotate function is not very easily tested. Here's what I did:

cd /var/log/privoxy
cat ../dracut.log >>logfile
# repeat above command until logfile is easily 1MB large
/sbin/logrotate /etc/logrotate.conf
# logrotate should not complain
# the dir should now contain an empty "logfile" and the large "logfile.1"
fuser /var/log/privoxy/*

The output of the fuser command should be
  logfile: <n>
and NOT
  logfile.1: <n> .

# remove (mostly) bogus logfile
rm -f logfile.1

After testing, change back the browser settings (and remove the privoxy package).
Comment 7 Christiaan Welvaart 2014-10-25 20:13:44 CEST
Updated packages are available for testing:

Source RPM:

Binary RPMS:

Source RPM:

Binary RPMS:

Proposed advisory:

Updated privoxy packages fix a security issue:

The logrotate configuration of the privoxy package did not function properly, causing its log files not to be rotated. The log file(s) could potentially fill up the disk.

Assignee: cjw => qa-bugs

Comment 8 David Walser 2014-10-25 20:16:43 CEST
Looking it their Bugzilla, it looks like they've since discovered that reload indeed doesn't work and restart is needed (not fixed yet).  The NetworkManager thing appears to be just a bugfix not a security fix, but it looks like privoxy doesn't continue to work after a network interface config change and needs to be restarted.
Comment 9 David Walser 2014-10-25 20:18:48 CEST
Thanks Christiaan!


Updated privoxy package fixes security vulnerability:

The logrotate configuration of the privoxy package did not function properly,
causing its log files not to be rotated. The log file(s) could potentially
fill up the disk.

David Walser 2014-10-25 20:18:59 CEST

Version: Cauldron => 4
Whiteboard: MGA4TOO, MGA3TOO => MGA3TOO

Comment 10 Otto Leipälä 2014-10-26 11:37:52 CET
Here is how to configure it to testing.

CC: (none) => ozkyster

Comment 11 olivier charles 2014-10-28 18:04:06 CET
Testing on Mageia 4-64, real H/w

Based on comment 6 and comment 10, my procedure was :

With current package :

installed :
- privoxy-3.0.21-2.mga4.x86_64

- tor-
- lib64tsocks1-1.8-0.beta5.13.mga4.x86_64
- tsocks-1.8-0.benta5.13.mga4.x86_64

# cd /etc/tor/
# cp torrc.sample torrc
# nano /etc/torrc
and uncommented 
SocksPort 9050 # Default: Bind to localhost:9050 for local connections.
as user :
$ tor
and after a while :
Oct 28 17:25:51.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Oct 28 17:25:51.000 [notice] Bootstrapped 100%: Done.
and left it running

# nano /etc/privoxy/config
uncommented :
forward-socks5   /      .
forward         192.168.*.*/     .
forward            10.*.*.*/     .
forward           127.*.*.*/     .

in firefox settings (advanced, network, settings)
Proxy HTTP : localhost
Port : 8118
and deleted "No proxy for : localhost"

Restarted firefox, went to a dummy address and had a message from privoxy : 
This is Privoxy 3.0.21 on localhost (, port 8118, enabled
Forwarding failure

Went to http://whatismyipaddress.com/
which verified I had an anonymous tor IP address.

Stopped tor and privoxy services.
Installed updated-testing package privoxy-3.0.21-2.1.mga4

To be on the safe side, rebooted.
Tor and privoxy were running
In webbrowser, went to dummy address, to mageia site and to http://whatismyipaddress.com/
which confirmed I was using a tor address (Tor exit node located in Gulf of Guinea)

Tested the logrotate function as advised in comment 6
# cd /var/log/privoxy/
# cat ../shorewall-init.log >>logfile
when logfile was 1.1 Mb
# /sbin/logrotate /etc/logrotate.conf
As expected, /var/log/privoxy contained empty logfile and logfile.1 (1.1Mb)
# fuser /var/log/privoxy/* gave logfile: 11042 (and didn't mention logfile.1)

Worked well then

CC: (none) => olchal
Whiteboard: MGA3TOO => MGA3TOO MGA4-64-OK

Christiaan Welvaart 2014-11-11 02:09:50 CET

Whiteboard: MGA3TOO MGA4-64-OK => MGA3TOO MGA4-64-OK has_procedure

Comment 12 David Walser 2014-11-18 18:08:12 CET
Tested successfully Mageia 3 i586 and Mageia 4 i586 with the procedure in Comment 6.

Just curious, what purpose does the /var/log/privoxy/logfile serve?  It doesn't log anything when you browse through the proxy.

Whiteboard: MGA3TOO MGA4-64-OK has_procedure => MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64-OK has_procedure

Comment 13 Christiaan Welvaart 2014-11-18 18:14:50 CET
Here it logs every access because I have  "debug 1025" in the config file. The default value for the debug setting is 0 which (according to documentation) only logs errors fatal for the daemon.
Comment 14 olivier charles 2014-11-18 19:24:08 CET
Testing privoxy on Mageia3-64 HW, same procedure

Current package :
- privoxy-3.0.21-1.mga3.x86_64

with tor
- tor-
- tsocks-1.8-0.beta5.12.mga3.x86_64
- lib64tsocks1-1.8-0.beta5.12.mga3.x86_64

In /etc/privoxy/config,

I also uncommented to have more input in privoxy logfile (as I was curious after reading comment 12 from David):

  debug     1 # Log the destination for each request Privoxy let through. See also debug 1024.
  debug     2 # show each connection status
Tests ok, I could also verify that logfile was growing quite fast (more than 1 mb after visiting 6 sites)

  Updated to :
- privoxy-3.0.21-1.1.mga3.x86_64

Tests ok, logrotate functionning as expected, could stop and restart privoxy service.

Whiteboard: MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64-OK has_procedure => MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64-OK MGA3-64-OK has_procedure

Comment 15 David Walser 2014-11-18 19:35:44 CET
Thanks Olivier.

Validating now.

Could someone please upload the advisory?

Sysadmins, once the advisory is uploaded, please push to core/updates_testing.  Thanks.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Comment 16 Rémi Verschelde 2014-11-19 13:00:01 CET
Advisory uploaded.

CC: (none) => remi
Whiteboard: MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64-OK MGA3-64-OK has_procedure => MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64-OK MGA3-64-OK has_procedure advisory

Comment 17 Mageia Robot 2014-11-21 13:45:27 CET
An update for this issue has been pushed to Mageia Updates repository.


Resolution: (none) => FIXED

Comment 18 David Walser 2014-11-21 19:04:33 CET
LWN reference for the logrotate issue:

Note You need to log in before you can comment on or make changes to this bug.