Date: Thu, 06 Aug 2015 14:30:56 +0000 From: Jason Buberel <jbuberel@...gle.com> To: Martin Prpic <mprpic@...hat.com>, oss-security@...ts.openwall.com Cc: cve-assign@...re.org Subject: Re: Re: CVE Request - Go net/http library - HTTP smuggling Martin, We agree that that issue should be included in a 1.4.3 release under a 4th CVE ID. In addition, we would also like to include: https://go-review.googlesource.com/#/c/12865/ Which addresses the very closely related issue: https://golang.org/issue/11930 ...under the same (4th, not yet assigned) CVE ID. -jason On Thu, Aug 6, 2015 at 1:55 AM Martin Prpic <mprpic@...hat.com> wrote: > Hi, this looks like it needs a CVE as well: > > > https://github.com/golang/go/commit/26049f6f9171d1190f3bbe05ec304845cfe6399f > https://github.com/golang/go/issues/12027 > > Can you please assign one? Thank you! > > -- > Martin Prpič / Red Hat Product Security > > > cve-assign@...re.org writes: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > >> > https://github.com/golang/go/commit/117ddcb83d7f42d6aa72241240af99ded81118e9 > >> > >> * Invalid headers are parsed as valid headers (like "Content Length:" > with a > >> space in the middle) > > > > For purposes of CVE assignments, we feel that this needs to be > > categorized separately from the other parts of the report. The primary > > factor is that there are different sets of affected versions. This > > behavior apparently was not present in all versions of Go: it was > > added in February 2012. Also, it is not really an error in determining > > the semantics of a set of headers; it's a security-relevant error in > > interpretation of the syntax of an individual header. > > > > Use CVE-2015-5739. > > > > > >> > https://github.com/golang/go/commit/300d9a21583e7cf0149a778a0611e76ff7c6680f > >> > >> * Double Content-length headers in a request does not generate a 400 > error, > >> the second Content-length is ignored > > > > Use CVE-2015-5740 for the reporter's finding of a security-relevant > > RFC 7230 3.3.3 4 violation ("MUST respond with a 400 (Bad Request) > > status code"). > > > > > > 300d9a21583e7cf0149a778a0611e76ff7c6680f also has code changes that > > were not mentioned in your "as provided by the reporter" section. Our > > interpretation is that there were separate internal discoveries of > > other security-relevant RFC 7230 violations, such as "MUST NOT send a > > Content-Length header field in any message that contains a > > Transfer-Encoding header field." Use CVE-2015-5741 for one or more > > internal discoveries reflected in > > 300d9a21583e7cf0149a778a0611e76ff7c6680f. > > > > > > Finally, if there is a code change in > > 300d9a21583e7cf0149a778a0611e76ff7c6680f that is exclusively for the > > purposes of hardening (i.e., no RFC requires the change as a smuggling > > security fix, and the code change is not for addressing an > > individually exploitable problem), then that code change is outside > > the scope of CVE. > > > > - -- > > CVE assignment team, MITRE CVE Numbering Authority > > M/S M300 > > 202 Burlington Road, Bedford, MA 01730 USA > > [ PGP key available through http://cve.mitre.org/cve/request_id.html ] > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1 > > > > iQEcBAEBCAAGBQJVwjr0AAoJEKllVAevmvms4SgH/1K26OmJwLV0/D+IgSIcWq8q > > ecN2DlngcNpU7W/fq9o/brN4hoMGVzh/aEPU3JIqC0JbY0OhidPe/DZmqLcndnwb > > iQ4wS4r89akrzZpdOYc09oBlqyxKtto1exwFHWqqdVIbBjHdq+nQhEBwYGyjf/XK > > 0DyEX6f72Msa//HFhNKycOKM4KPKsi1Gh5Dl+L9nddWnPdTnTSHoIdD+RGmXDDkD > > 8i6WI/e5QVrGL2g24mrpefDUWX/p9T/cx9LR1hiiUUDuvns40NVz11E1i8PD2fv3 > > wRzEjUqyt94syYh9PNa0+ZFH7sPUyYOhnpi3/1UzRkSUSI++FfpDFrq3rOEZ4Jk= > > =rNSr > > -----END PGP SIGNATURE----- >
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.