Re: [openstack-dev] [Horizon][Security] BREACH/CRIME Attack Information
On 8 August 2013 02:07, Clark, Robert Graham wrote: > My understanding of such attacks is that they require a > point-of-presence within the browser to perform the injection which in > turn enables the side channel. As clients/users won't be interacting > with the API using a browser I'm not 100% convinced that we need to > worry about defending against BREACH/CRIME on the API endpoints but that > *Horizon is a valid concern*. They need a means to trigger repeated *responses* with slightly differing payloads. One way to trigger that would be code that asks for the same thing thousands of times : which btw a lot of our infrastructure does :(. > I've not checked but I doubt the API endpoints use transport > compression, meaning that even if a user were to attempt to interact > with an endpoint directly using a compromised browser the attack would > not succeed. Any compression that leaks sufficient size data in a side channel will do AIUI, whether it's entity compression, header compression or transport compression. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon][Security] BREACH/CRIME Attack Information
My understanding of such attacks is that they require a point-of-presence within the browser to perform the injection which in turn enables the side channel. As clients/users won't be interacting with the API using a browser I'm not 100% convinced that we need to worry about defending against BREACH/CRIME on the API endpoints but that *Horizon is a valid concern*. I've not checked but I doubt the API endpoints use transport compression, meaning that even if a user were to attempt to interact with an endpoint directly using a compromised browser the attack would not succeed. > -Original Message- > From: Robert Collins [mailto:robe...@robertcollins.net] > Sent: 07 August 2013 10:21 > To: OpenStack Development Mailing List > Subject: Re: [openstack-dev] [Horizon][Security] BREACH/CRIME Attack > Information > > On 7 August 2013 20:30, Thierry Carrez wrote: > > Gabriel Hurley wrote: > >> Many of you have probably heard about the "BREACH" attack/security > vulnerability in HTTPS traffic that was disclosed recently, and I'd like to take > a moment to provide some info about how that affects Horizon. I'm not > following the official vulnerability management process because 1. The > vulnerability is already disclosed publicly, 2. Workaround information has > already been published by Django and many others, and 3. There's no one- > off code fix on our end so awareness is the best possible thing. > > > > Agree that there is nothing to patch in our code at this point and > > therefore no base for an OpenStack Security Advisory (OSSA). The > > information you provided would still make a great OpenStack Security > > Note (OSSN), though. Those are issued by the OpenStack Security Group, > > I CC-ed Rob Clark so that he puts it on his radar. > > Note that our API services are likely a rich target too - when running under > SSL it should be fairly straight forward to get minor changes to the payload > from keystone (e.g. with repeated token calls - but I don't know the API well > enough to speculate in detail). > > -Rob > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon][Security] BREACH/CRIME Attack Information
On 7 August 2013 20:30, Thierry Carrez wrote: > Gabriel Hurley wrote: >> Many of you have probably heard about the "BREACH" attack/security >> vulnerability in HTTPS traffic that was disclosed recently, and I'd like to >> take a moment to provide some info about how that affects Horizon. I'm not >> following the official vulnerability management process because 1. The >> vulnerability is already disclosed publicly, 2. Workaround information has >> already been published by Django and many others, and 3. There's no one-off >> code fix on our end so awareness is the best possible thing. > > Agree that there is nothing to patch in our code at this point and > therefore no base for an OpenStack Security Advisory (OSSA). The > information you provided would still make a great OpenStack Security > Note (OSSN), though. Those are issued by the OpenStack Security Group, I > CC-ed Rob Clark so that he puts it on his radar. Note that our API services are likely a rich target too - when running under SSL it should be fairly straight forward to get minor changes to the payload from keystone (e.g. with repeated token calls - but I don't know the API well enough to speculate in detail). -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon][Security] BREACH/CRIME Attack Information
Gabriel Hurley wrote: > Many of you have probably heard about the "BREACH" attack/security > vulnerability in HTTPS traffic that was disclosed recently, and I'd like to > take a moment to provide some info about how that affects Horizon. I'm not > following the official vulnerability management process because 1. The > vulnerability is already disclosed publicly, 2. Workaround information has > already been published by Django and many others, and 3. There's no one-off > code fix on our end so awareness is the best possible thing. Agree that there is nothing to patch in our code at this point and therefore no base for an OpenStack Security Advisory (OSSA). The information you provided would still make a great OpenStack Security Note (OSSN), though. Those are issued by the OpenStack Security Group, I CC-ed Rob Clark so that he puts it on his radar. Thanks! -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon][Security] BREACH/CRIME Attack Information
Many of you have probably heard about the "BREACH" attack/security vulnerability in HTTPS traffic that was disclosed recently, and I'd like to take a moment to provide some info about how that affects Horizon. I'm not following the official vulnerability management process because 1. The vulnerability is already disclosed publicly, 2. Workaround information has already been published by Django and many others, and 3. There's no one-off code fix on our end so awareness is the best possible thing. First off, here's a link to information on the vulnerability: http://breachattack.com/ The short version is that the attack uses carefully constructed "guess-and-check" insertions into compressed HTTPS streams to deduce secret data transmitted across those streams character by character. For Horizon, those secrets would be things like Keystone auth tokens and CSRF tokens. The simplest "fix" for Django (as detailed in the Django security advisory linked below) is not to use Django's GZip compression middleware and to turn off any body compression you may have enabled in other intermediate webserver or proxy layers. Here's Django's security advisory: https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/ This only applies if you're using HTTPS (you *are* using HTTPS, right?) and the GZip middleware or other body compression currently. The tradeoff for disabling the compression is that outgoing data transfer will generally be 40-60% larger. In the longer term there are current discussions outside the OpenStack community about ways to further strengthen CSRF protection, SSL encryption, etc. but there's no general-purpose fix here. At the very least, the scope of the vulnerability in Horizon is limited to a certain set of configurations, and attacking a single user + single session at a time. Depending on your deployments constraints it can be mitigated to varying degrees or eliminated entirely at a certain cost. As the web community continues to address this widespread problem there will likely be further information to disseminate. Thanks for your attention, - Gabriel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
