Bugzilla – Bug 945206
VUL-0: CVE-2015-5245: ceph: RGW returns requested bucket name raw in Bucket response header
Last modified: 2016-04-27 19:12:38 UTC
reported by the upstrea: PCI scans have determined that the RGW is returning whatever string it thought was the name of the bucket requested as raw text in the Bucket response header, which we are using to be able to track request/response cycles by bucket. The result is that things like this are possible (note the extra Content-type header): <snip> $ curl -i "objects.dreamhost.com/nothing-to-see-here%22%0D%0AContent-type%3A%20%22image-jpg";echo HTTP/1.1 400 Bad Request Bucket: "nothing-to-see-here" Content-type: "image-jpg" Content-Length: 83 Accept-Ranges: bytes Content-type: application/xml Date: Mon, 27 Jul 2015 22:57:11 GMT <Error><Code>InvalidBucketName</Code></Error> </snip> This could be considerably worse. It is in fact trivial to make the RGW return invalid HTTP responses this way as well (the resulting response is from HAProxy rejecting the invalid response from the RGW, as it should): </snip> $ curl -i "objects.dreamhost.com/nothing-to-see-here%22%0D%0AContent-Length%3A%20%2282";echo HTTP/1.0 502 Bad Gateway Cache-Control: no-cache Connection: close Content-Type: text/html <html><body><h1>502 Bad Gateway</h1> The server returned an invalid or incomplete response. </body></html> </snip> The RGW needs to sanitize/clean-up the bucket name before including it in the bucket header, by encoding the data in a standard encoding so that it is impossible to do things like inserting new headers, data, etc.. that looks like meaningful parts of a real HTTP response. References: http://tracker.ceph.com/issues/12537 https://bugzilla.redhat.com/show_bug.cgi?id=1261606 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-5245 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5245
bugbot adjusting priority
In order to reproduce this behaviour, one first needs to enable the rgw_expose_bucket option in the cluster configuration file and reload radosgw. /etc/ceph/ceph.conf: ... [client.radosgw.sle12-ceph-2] ... rgw_expose_bucket = true ... Test case (confirms bug): % curl -i "http://sle12-ceph-2:7480/nothing-to-see-here%22%0D%0AContent-type%3A%20%22image-jpg"; echo HTTP/1.1 400 Bad Request Bucket: nothing-to-see-here" ---------------------------- Content-type: "image-jpg ------------------------ Content-Length: 83 Accept-Ranges: bytes Content-type: application/xml Date: Sat, 12 Sep 2015 01:23:24 GMT <?xml version="1.0" encoding="UTF-8"?><Error><Code>InvalidBucketName</Code></Error> Backporting the fix pointed to by the upstream report: https://github.com/ceph/ceph/commit/ad5507fe0bf72ed5bdf8353e315cc9092c740144 successfully fixes the bug. Re-test (successful fix): % curl -i "http://sle12-ceph-2:7480/nothing-to-see-here%22%0D%0AContent-type%3A%20%22image-jpg"; echo HTTP/1.1 400 Bad Request Bucket: nothing-to-see-here%22%0D%0AContent-type%3A%20%22image-jpg ------------------------------------------------------------------ Content-Length: 83 Accept-Ranges: bytes Content-type: application/xml Date: Sat, 12 Sep 2015 01:24:44 GMT <?xml version="1.0" encoding="UTF-8"?><Error><Code>InvalidBucketName</Code></Error>
Downstream PR: https://github.com/SUSE/ceph/pull/19 Upstream master PR: http://tracker.ceph.com/issues/12537 https://github.com/ceph/ceph/pull/5430 Hammer backport: http://tracker.ceph.com/issues/12592 https://github.com/ceph/ceph/pull/5715 -> staged for 0.94.4 Now building in 2.0:Staging, Revision 73: https://build.suse.de/package/rdiff/Devel:Storage:2.0:Staging/ceph?linkrev=base&rev=73
PR merged into suse-0-94-3 and building in Devel:Storage:2.0:Staging/ceph. Marking as fixed.
Does this affects shipped ceph? on just SES 1 or also on the SLES client packages? Never close security bugs unless everything is released, reassiugn to security-team once all submits have taken place.
(In reply to Marcus Meissner from comment #6) > Does this affects shipped ceph? > > on just SES 1 or also on the SLES client packages? > > > Never close security bugs unless everything is released, reassiugn to > security-team once all submits have taken place. Hi Marcus, Thanks for the information. This bug would affect SES1 as well. However, as I understand it, we have not external customers for SES1. Fixing this in SES2 should be sufficient. Mili - could you please confirm? -Karol
Well, we are trying to sell it, right? Unless its declared EOLed we should do updates.
Upstream 0.80.11 is around the corner and it contains this PR which fixes the bug: https://github.com/ceph/ceph/pull/5730
A new ceph package containing the fix for this issue has been built in Devel:Storage:1.0:Staging and will now move through our automated internal testing process.
SES1 maintenance update submitted: > smithfarm@wilbur:~/src/ceph/SUSE/ceph> iosc mr -m "update SES1 to latest upstream version" Devel:Storage:1.0 ceph SUSE:SLE-12:Update:Products:Cloud5:Update > Using target project 'SUSE:Maintenance' > 95418
Handed over to maintenance.
SUSE-SU-2016:0806-1: An update that solves one vulnerability and has 5 fixes is now available. Category: security (moderate) Bug References: 926756,931451,941628,945206,964907,965619 CVE References: CVE-2015-5245 Sources used: SUSE Enterprise Storage 1.0 (src): ceph-0.80.11-8.1