Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 1 Mar 2015 06:57:32 +0100
From: Jerome Athias <athiasjerome@...il.com>
To: oss-security@...ts.openwall.com
Cc: Assign a CVE Identifier <cve-assign@...re.org>, jvn@....jp
Subject: Re: CVE-2015-0881

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@...hat.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@...id-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
>

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ