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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ