CVEs have been requested for security issues fixed in privoxy 3.0.23: http://openwall.com/lists/oss-security/2015/01/26/4 Mageia 4 is also affected. Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA4TOOCC: (none) => cjw
Packages are ready for testing: MGA4 SRPM: privoxy-3.0.21-2.3.mga4.src.rpm RPMS: privoxy-3.0.21-2.3.mga4.i586.rpm privoxy-3.0.21-2.3.mga4.x86_64.rpm For a test procedure, see https://bugs.mageia.org/show_bug.cgi?id=14892#c9 Proposed advisory: Updated privoxy packages fix security issues: Fixed a DoS issue in case of client requests with incorrect chunk-encoded body. When compiled with assertions enabled (the default) they could previously cause Privoxy to abort(). Fixed multiple segmentation faults and memory leaks in the pcrs code. This fix also increases the chances that an invalid pcrs command is rejected as such. Previously some invalid commands would be loaded without error. Note that Privoxy's pcrs sources (action and filter files) are considered trustworthy input and should not be writable by untrusted third-parties. Fixed an 'invalid read' bug which could at least theoretically cause Privoxy to crash. References: http://openwall.com/lists/oss-security/2015/01/26/4 http://www.privoxy.org/announce.txt
Assignee: cooker => qa-bugs
Thanks Christiaan! He also requested a freeze push for Cauldron.
CC: (none) => cookerVersion: Cauldron => 4Whiteboard: MGA4TOO => (none)
Whiteboard: (none) => has_procedure
Testing on Mageia 4x32 real hardware, following procedure mentioned in Comment 1 From current package : -------------------- privoxy-3.0.21-2.2.mga4 previously tested in https://bugs.mageia.org/show_bug.cgi?id=14892 To updated testing package : -------------------------- privoxy-3.0.21-2.3.mga4 # systemctl start privoxy.service # systemctl status -l privoxy.service privoxy.service - Privacy enhancing HTTP Proxy Loaded: loaded (/usr/lib/systemd/system/privoxy.service; enabled) Active: active (running) since lun. 2015-01-26 22:05:39 CET; 8s ago Configured firefox to use proxy localhost:8118 Browsed to http://www.n.zz/ 404 This is Privoxy 3.0.21 on localhost (127.0.0.1), port 8118, enabled Browsed to http://ad.example.com/ BLOCKED This is Privoxy 3.0.21 on localhost (127.0.0.1), port 8118, enabled Request for blocked URL Your request for http://ad.example.com/ was blocked. Block reason: Host matches generic block pattern. # systemctl stop privoxy.service Updated testing package OK
CC: (none) => olchalWhiteboard: has_procedure => has_procedure MGA4-32-OK
Testing complete mga4 64, same procedure Validating. Please push to 4 updates Thanks
CC: (none) => sysadmin-bugsKeywords: (none) => validated_updateWhiteboard: has_procedure MGA4-32-OK => has_procedure MGA4-32-OK mga4-64-ok
David, do you wish to add cve's and references to the advisory?
(In reply to claire robinson from comment #5) > David, do you wish to add cve's and references to the advisory? I'd like to, but no CVEs have been assigned yet. I think we pushed the last update out before they were assigned too.
Advisory uploaded as-is from comment 1.
Whiteboard: has_procedure MGA4-32-OK mga4-64-ok => has_procedure advisory MGA4-32-OK mga4-64-ok
CVEs have been assigned: http://openwall.com/lists/oss-security/2015/01/27/20 Updated advisory (needs committed in SVN)... Updated privoxy packages fix security issues: Fixed a DoS issue in case of client requests with incorrect chunk-encoded body. When compiled with assertions enabled (the default) they could previously cause Privoxy to abort() (CVE-2015-1380). Fixed multiple segmentation faults and memory leaks in the pcrs code. This fix also increases the chances that an invalid pcrs command is rejected as such. Previously some invalid commands would be loaded without error. Note that Privoxy's pcrs sources (action and filter files) are considered trustworthy input and should not be writable by untrusted third-parties (CVE-2015-1381). Fixed an 'invalid read' bug which could at least theoretically cause Privoxy to crash (CVE-2015-1382). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1380 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1381 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-1382 http://www.privoxy.org/announce.txt http://openwall.com/lists/oss-security/2015/01/27/20
Summary: privoxy new security issues fixed upstream in 3.0.23 => privoxy new security issues fixed upstream in 3.0.23 (CVE-2015-138[0-2])Whiteboard: has_procedure advisory MGA4-32-OK mga4-64-ok => has_procedure MGA4-32-OK mga4-64-ok
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGASA-2015-0042.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
Aack, I guess the robot doesn't check for the advisory tag in the whiteboard, it only checks for an advisory in SVN, so it'll still push it even though there's an outdated advisory in SVN, which happened in this case. Can we please fix this?
CC: (none) => mageia
(In reply to David Walser from comment #10) > Aack, I guess the robot doesn't check for the advisory tag in the > whiteboard, it only checks for an advisory in SVN, so it'll still push it > even though there's an outdated advisory in SVN, which happened in this > case. Can we please fix this? It checks for validated_update in keywords. If the update is validated it is assigned an ID when the updates are processed by an authorised user. If the update is not validated, then the validated_update keyword should be removed. I don't really see why the tool should have to check multiple things in this regard, but if you feel strongly I can take a look (note there is no current code for checking "Whiteboard" in the tool and thus it's not just a couple lines to add an additional keyword check - perhaps we could move the "advisory" whiteboard text into a "validated_advisory" keyword, thus making it more robust - AFAIK, whiteboard can have any text and thus building an API around something that could be misspelled seems a bit risky - IMO if this is going to have "meaning" it should probably be more strongly defined)
Just restating what I said in IRC: Whether the update is sufficiently tested to be validated, and whether an up to date advisory exists in SVN, are two completely different things, and they mean different things to the QA team We're not going to unvalidate something just because the advisory needs to be changed, that sends an entirely different message about what needs to be done If you want us to change our keyword or something, that's fine. I would ask Claire about that. But it does needs to keep these two issues separate If anyone else has thoughts about managing this with keywords vs. the whiteboard, feel free to chime in.
URL: (none) => http://lwn.net/Vulnerabilities/630953/