Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 1 Mar 2015 06:57:32 +0100
From: Jerome Athias <>
Cc: Assign a CVE Identifier <>,
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

My 2c

2015-02-23 16:34 GMT+01:00 Kurt Seifried <>:
> Regarding CVE-2015-0881
> 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 (
>>> bounced), there's no security report, and no link to a source code
>>> patch for this.
>> - From the "Contact Us page"
>> (<>)
>>   squid-bugs @
>> ... 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:
>> <>
>> (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

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.