Buffer overflow in the gopherToHTML function in gopher.cc in the Gopher reply parser in Squid 3.0 before 3.0.STABLE26, 3.1 before 3.1.15, and 3.2 before 3.2.0.11 allows remote Gopher servers to cause a denial of service (memory corruption and daemon restart) or possibly have unspecified other impact via a long line in a response. Patch available on http://www.squid-cache.org/Versions/v3/3.1/changesets/squid-3.1-10363.patch
Version: Cauldron => 1
Hardware: i586 => All
Assignee: bugsquad => dlucio
squid 3.1.15 is in updates_testing
CC: (none) => dlucioAssignee: dlucio => qa-bugs
Theres no exploit for this so we can only test it functions correctly. x86_64: Set up squid using a youtube tutorial at http://www.youtube.com/watch?v=MMadVJNoD48 Verified acl times and sites http_access Verified cachemgr at localhost/cgi-bin/cachemgr.cgi All seems OK.
I notice in /var/log/squid/squid.out WARNING: -D command-line option is obsolete. when it starts, which appears in /etc/init.d/squid
i586: Tested OK squid and squid-cachemgr. The -D thing doesn't seem to have any obvious effect. Is it something you need to look at? I will validate if not.
Assigning for confirmation. Please reassign to QA when you've had a look. Thanks.
CC: (none) => qa-bugsAssignee: qa-bugs => manuel
Reassign to the write maintainer.
Assignee: manuel => dlucio
http://squidcache.cybermirror.org/squid/squid-3.1.14-RELEASENOTES.html#ss3.3 Looks like the -D option was used to allow squid to start before bind, but is no longer needed. Leaving it in seems to be a cosmetic issue, and not worth holding up the update. I'm going ahead and validating the update. Can someone from the sysadmin team push the srpm squid-3.1.15-1.1.mga1.src.rpm from Core Updates Testing to Core Updates. Advisory: A buffer overflow in gopher.cc allowed accessing a malicious gopher server to crash squid. This update fixes the issue. https://bugs.mageia.org/show_bug.cgi?id=2778
Keywords: (none) => validated_updateCC: (none) => davidwhodgins, sysadmin-bugsAssignee: dlucio => qa-bugs
Cosmetic -D issue is fixed, no messages anymore.
Guess I jumped the gun in validating the update then. An updated version without the -D is not on my local i586 mirror. I'll hold off validating the update till it shows up, and I can test it again.
Keywords: validated_update => (none)
CC: sysadmin-bugs => (none)
Something is wrong. root@hodgins ~]# grep -i squid /var/log/prcsys.log squid is stopped squid: ERROR: No running copy squid is stopped squid: ERROR: No running copy [root@hodgins ~]# service squid start init_cache_dir ... Starting squid: . [ OK ] While the service can be started after booting, it's failing to start on a reboot.
Ignore comment 10. Forgot I'd disabled the squid service a while ago, while testing something else. The messages were from the loopback and eth0 startup.
Testing complete for i586. I configured opera to use 127.0.0.1 port 3128 as a proxy, and after browsing for a while, compared the /var/log/squid/access.log to the description from http://firewall.at/support/squid/Users-Guide/x922.html confirming that it was caching items. Also, the error message regarding -D is no longer being added. The srpm is squid-3.1.15-1.2.mga1.src.rpm
Testing complete for x86_64 Installing squid pulled in as dependencies perl-Authen-Smb-0.910.0-5.mga1 lib64db5.1-5.1.19-6.mga1 lib64ecap0-0.0.3-1.mga1 Bug 2317 means these will have to be linked to the update repository. Yes, or is that just for new dependencies?
CC: (none) => derekjenn
It will be new dependencies in this case Derek because it's MageiaUpdate which is affected by bug 2317. Installing through rpmdrake from Updates is Ok. Our mostly working script does say that libdb5.1 is a new dependency from Core Release though. (libdb5.1-5.1.19-6.mga1) This will be a good test for it.
Sophie does confirm a dependency has changed from libdb4.8 to libdb5.1 so the script looks to be working :o) There are still parts which aren't (it's going through QA!) but when it is ready it will be a useful QA tool.
I used a clean install with squid installed from core release. After adding the core updates testing repository, the update did indeed install libdb5.1 from core release, so it will have to be linked to updates. Both of the requires from libdb5.1 are included in base-system-minimal, so those are ok.
Validating the update. Can someone from the sysadmin team push the srpm squid-3.1.15-1.2.mga1.src.rpm From Core Updates Testing to Core Updates. Also, link the package ... libdb5.1/lib64db5.1 from Core Release to Core Updates. Advisory: A buffer overflow in gopher.cc allowed accessing a malicious gopher server to crash squid. This update fixes the issue.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
update pushed.
Status: NEW => RESOLVEDCC: (none) => dmorganecResolution: (none) => FIXED
I've noticed that squid-debug is still in Core Updates Testing Debug Doesn't the pushing of an srpm also push the associated debug packages?
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
(In reply to comment #19) > I've noticed that squid-debug is still in > Core Updates Testing Debug No, they are in in updates degug now. Maybe your mirror was not up to date. > > Doesn't the pushing of an srpm also push the associated debug > packages? Yes, it should.
Status: REOPENED => RESOLVEDCC: (none) => boklmResolution: (none) => FIXED
CC: boklm => (none)