Bugzilla – Bug 920576
VUL-2: CVE-2015-0881: squid: CRLF injection vulnerability in allows remote attackers to inject arbitrary HTTP content
Last modified: 2015-11-10 14:58:35 UTC
CVE-2015-0881 CRLF injection vulnerability in Squid before 3.1.10 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via a crafted header in a response. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-0881 http://seclists.org/oss-sec/2015/q1/632 http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-0881.html http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0881 http://www.cvedetails.com/cve/CVE-2015-0881/ http://jvn.jp/en/jp/JVN64455813/index.html http://jvndb.jvn.jp/jvndb/JVNDB-2015-000019
Details about the vulnerability are sparse. No patches are available currently, only that it was fixed in 3.1 From: Amos Jeffries <squid3@treenet.co.nz> JPCERT has now provided me a copy of the attack. They have requested I not reveal the details, so I am treating that and the patch details as embargoed for the time being. Without revealing too much (I hope) I can confirm: * It is a known vulnerability - to upstream that is, but no CVE assigned. * The initial report of this issue to upstream occured during 2009. * Squid 1.x, 2.x, and 3.0 releases are all vulnerable. * All Squid-3.1 stable releases are not vunerable. - eg, you can bump the fixed version number back to 3.1.1 for most OS distributions.
bugbot adjusting priority
(In reply to Swamp Workflow Management from comment #2) From: Amos Jeffries Patch is <http://www.squid-cache.org/Versions/v3/3.1/changesets/b9619.patch> if you want to try back-porting. Take care though if you do, all the earlier versions have different logics surrounding how the connection data gets accounted.
all our instances of squid3 are > 3.1.1 (with the patch already applied), same goes for squid in all maintained openSUSEs and SLE12 squid 2 in SLE10 and SLE11 seems to be vulnerable. which is unfortunate, because between 2 and 3 squid was rewritten from C to C++, and the comment from Amos about different logic is accurate :(
An update workflow for this issue was started. This issue was rated as moderate. Please submit fixed packages until 2015-04-03. When done, reassign the bug to security-team@suse.de. https://swamp.suse.de/webswamp/wf/61243
i'm going to miss the deadline, i still have no idea what to do with this basically, it's unclear to me what the patch from comment #3 accomplishes and how to backport it to squid2 code which is very different. also, I don't have any sort of reproducer or at least the exploit basis, so I can't recreate the mitigation, or even confirm that squid 2 is vulnerable, i'm going on Amos's word that it is. security team, a little help here? alternately, we can decide that having a fixed squid3 is OK (we have that), and keep squid2 as it is. that's what other distros seem to have done.
i canceled the swamp for now until patches are available. have to either look myself or find someone :?
An update workflow for this issue was started. This issue was rated as important. Please submit fixed packages until 2015-10-23. When done, reassign the bug to security-team@suse.de. https://swamp.suse.de/webswamp/wf/62312