oss-sec mailing list archives
Re: CVE-2015-0881
From: Jerome Athias <athiasjerome () gmail com>
Date: Sun, 1 Mar 2015 06:57:32 +0100
I just disagree with rational 1) -in general-, e.g. SCADA and ICS systems running 5+ years outdated softwares and hardwares simple cross-reference of some vulnerabilities databases give attribution http://www.securityfocus.com/bid/72703/info My 2c 2015-02-23 16:34 GMT+01:00 Kurt Seifried <kseifried () redhat com>:
Regarding CVE-2015-0881 http://jvn.jp/en/jp/JVN64455813/index.html http://jvndb.jvn.jp/en/contents/2015/JVNDB-2015-000019.html Unless JVN can provide more details I would like to recommend we CVE REJECT this issue based on the following rational: 1) It's an issue discovered "today" in software that was supposedly fixed 5 years ago 2) No information on the vuln or the specific fix has been made vulnerable, which may be ok for closed source vendors using CVE but this leads to point 3... 3) Even the upstream project can't make sense of this, and I'm inclined to trust them (e.g. they are not playing the "we want to minimize the number of CVE's assigned against our software game like some vendors). I would suggest if JVN doesn't get back to us within a week (this seems like more then enough time) that this CVE be REJECT'ed. Mitre: thoughts or comments? On 22/02/15 04:37 AM, Amos Jeffries wrote:On 22/02/2015 7:17 p.m., Kurt Seifried wrote:I'm trying to track down information on CVE-2015-0881.I can't find a squid security contact (security () squid-cache org bounced), there's no security report, and no link to a source code patch for this.- From the "Contact Us page" (<http://www.squid-cache.org/Support/contact.html>) squid-bugs @ lists.squid-cache.org ... which goes to me and some other trusted developers. I dont mind direct contacts for this type of thing, but the main contact address guarantees someone sees it within a few hrs. Regarding the CVE: 1) This is the first I've heard about this particular CVE number assignment. 2) I did have some discusions with JPCERT about _a_ response splitting vulnerability around those years. But the messages from them were IIRC about replicating response splitting in a 2.x versions which were incompletely fixed by: <http://www.squid-cache.org/Versions/v2/2.5/bugs/#squid-2.5.STABLE7-header_parsing> (did not get a CVE AFAIK). 3) I have not been able to replicate the #2 issue in the Squid-3 series and several iterations of changes to the parsers there have been careful to take the above issue into account. So I'm not sure where the 3.1.10 comes from. Assuming it is the same vulnerability.This is regarding 3.1.9 and earlier, 3.1.10 was released on 22 Dec 2010, so 4+ years ago.Needless to say I am more than a bit confused. A link to a specific code patch/vuln/file would be helpful. Also if anyone knows how to contact Squid re security issues properly I'd love to know.I'm not sure 3.1.10 is the right version for attribution on any response splitting fix. There certainly were no patches solving anything related to respinse splitting in that version. Some borderline memory leak vulnerabilities perhapse, but not response splitting. NP: Just to confuse things there was a major replacement of the HTTP request-line parser on the 2015-02-10 which does explicitly fix all lot of known HTTP request-line parse issues, including a few response splitting vectors using downgrade to HTTP/0.9 handling. That will only be in the 3.6 series though. Amos Jeffries Squid Software Foundation-- Kurt Seifried -- Red Hat -- Product Security -- Cloud PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Current thread:
- CVE-2015-0881 Kurt Seifried (Feb 21)
- Re: CVE-2015-0881 C Peters (Feb 21)
- Re: CVE-2015-0881 Kurt Seifried (Feb 21)
- Re: CVE-2015-0881 Amos Jeffries (Feb 22)
- Re: CVE-2015-0881 Kurt Seifried (Feb 23)
- Re: CVE-2015-0881 Amos Jeffries (Feb 28)
- Re: CVE-2015-0881 Kurt Seifried (Mar 01)
- Re: CVE-2015-0881 Amos Jeffries (Mar 06)
- Re: CVE-2015-0881 Kurt Seifried (Feb 23)
- Re: CVE-2015-0881 Jerome Athias (Feb 28)
- Re: CVE-2015-0881 C Peters (Feb 21)