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:
Wonderful this is indeed broken in cauldron, I guess it wasn't a bad idea to move packages I maintain (sendmail) 100% to systemd.
Nope I used a very old privoxy, guess I should now fix issues I had in the new version.
So we don't need an ExecReload or a NM config?
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.
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.
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:
cat ../dracut.log >>logfile
# repeat above command until logfile is easily 1MB large
# logrotate should not complain
# the dir should now contain an empty "logfile" and the large "logfile.1"
The output of the fuser command should be
logfile.1: <n> .
# remove (mostly) bogus logfile
rm -f logfile.1
After testing, change back the browser settings (and remove the privoxy package).
Updated packages are available for testing:
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.
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.
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.
MGA4TOO, MGA3TOO =>
Here is how to configure it to testing.
Testing on Mageia 4-64, real H/w
Based on comment 6 and comment 10, my procedure was :
With current package :
# cd /etc/tor/
# cp torrc.sample torrc
# nano /etc/torrc
SocksPort 9050 # Default: Bind to localhost:9050 for local connections.
as user :
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
forward-socks5 / 127.0.0.1:9050 .
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 (127.0.0.1), port 8118, enabled
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
MGA3TOO MGA4-64-OK =>
MGA3TOO MGA4-64-OK has_procedure
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.
MGA3TOO MGA4-64-OK has_procedure =>
MGA3TOO MGA3-32-OK MGA4-32-OK MGA4-64-OK has_procedure
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.
Testing privoxy on Mageia3-64 HW, same procedure
Current package :
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 :
Tests ok, logrotate functionning as expected, could stop and restart privoxy service.
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
Could someone please upload the advisory?
Sysadmins, once the advisory is uploaded, please push to core/updates_testing. Thanks.
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
An update for this issue has been pushed to Mageia Updates repository.
LWN reference for the logrotate issue: