<div dir="ltr">Just a note this was assigned CVE-2016-8611</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 27, 2016 at 3:42 PM, Luke Hinds <span dir="ltr"><<a href="mailto:lhinds@redhat.com" target="_blank">lhinds@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Glance Image service v1 and v2 api image-create vulnerability<br>
---<br>
<br>
### Summary ###<br>
No limits are enforced within the Glance image service for both v1 and<br>
v2 `/images` API POST method for authenticated users, resulting in<br>
possible denial of service attacks through database table saturation.<br>
<br>
### Affected Services / Software ###<br>
All versions of Glance image service.<br>
<br>
### Discussion ###<br>
Within the Glance image service, calls to the POST method within v1 or<br>
v2/images creates an image (record) in `queued` status. There is no<br>
limit enforced within the Glance API on the number of images a single<br>
tenant may create, just on the total amount of storage a single user may<br>
consume.<br>
<br>
Therefore a user could either maliciously or unintentionally fill<br>
multiple database tables (images, image_properties, image_tags,<br>
image_members) with useless image records, thereby causing a denial of<br>
service by lengthening transaction response times in the Glance database.<br>
<br>
### Recommended Actions ###<br>
For all versions of Glance that expose either the v1 and v2/images API,<br>
operators are recommended to deploy external rate-limiting proxies or<br>
web application firewalls, to provide a front layer of protection to<br>
glance. The Glance database should be monitored for abnormal growth.<br>
Although rate-limiting does not eliminate this attack vector, it will<br>
slow it to the point where you can react prior to a denial of service<br>
occurring.<br>
<br>
The following solutions may be considered, however it is key that the<br>
operator carefully plans and considers the individual performance needs<br>
of users and services within their OpenStack cloud, when configuring any<br>
rate limiting functionality.<br>
<br>
#### Repose ####<br>
Repose provides a rate limiting filter, that can utilise limits by IP,<br>
Role (OpenStack Identity v3 filter) or header.<br>
<br>
<a href="https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter" rel="noreferrer" target="_blank">https://repose.atlassian.net/<wbr>wiki/display/REPOSE/Rate+<wbr>Limiting+Filter</a><br>
<br>
#### NGINX ####<br>
NGINX provides the limit_req_module, which can be used to provide a<br>
global rate<br>
limit. By means of a `map`, it can be limited to just the POST method.<br>
<br>
Further details can be found on the nginx site:<br>
<a href="http://nginx.org/en/docs/http/ngx_http_limit_req_module.html" rel="noreferrer" target="_blank">http://nginx.org/en/docs/http/<wbr>ngx_http_limit_req_module.html</a><br>
<br>
#### HAProxy ####<br>
HAProxy can provide inherent rate-limiting using stick-tables with a General<br>
Purpose Counter (gpc)<br>
<br>
Further details can be found on the haproxy website:<br>
<br>
<a href="http://blog.haproxy.com/2012/02/27/use-a-load-balancer-as-a-first-row-of-defense-against-ddos" rel="noreferrer" target="_blank">http://blog.haproxy.com/2012/<wbr>02/27/use-a-load-balancer-as-<wbr>a-first-row-of-defense-<wbr>against-ddos</a><br>
<br>
#### Apache ####<br>
A number of solutions can be explored here as follows.<br>
<br>
##### mod_ratelimit #####<br>
<a href="http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html" rel="noreferrer" target="_blank">http://httpd.apache.org/docs/<wbr>2.4/mod/mod_ratelimit.html</a><br>
<br>
##### mod_qos #####<br>
<a href="http://opensource.adnovum.ch/mod_qos/dos.html" rel="noreferrer" target="_blank">http://opensource.adnovum.ch/<wbr>mod_qos/dos.html</a><br>
<br>
##### mod_evasive #####<br>
<a href="https://www.digitalocean.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7" rel="noreferrer" target="_blank">https://www.digitalocean.com/<wbr>community/tutorials/how-to-<wbr>protect-against-dos-and-ddos-<wbr>with-mod_evasive-for-apache-<wbr>on-centos-7</a><br>
<br>
##### mod_security #####<br>
<a href="https://www.modsecurity.org/" rel="noreferrer" target="_blank">https://www.modsecurity.org/</a><br>
<br>
#### Limit `add_image` to admin role ####<br>
<br>
Another possible mitigation is to restrict image creation to the admin<br>
role, however this should only be done for those cases in which there<br>
are Glance nodes dedicated to end-user access only. Restriction to admin<br>
only on Glance nodes that serve OpenStack services will for example,<br>
remove the ability to create snapshots from the Compute API or to create<br>
bootable volumes from Cinder.<br>
<br>
To restrict image creation to the role admin only, amend<br>
`/etc/glance/policy.json` accordingly.<br>
<br>
"add_image": "role:admin",<br>
<br>
### Contacts / References ###<br>
Author: Luke Hinds, Red Hat<br>
This OSSN : <a href="https://wiki.openstack.org/wiki/OSSN/OSSN-0076" rel="noreferrer" target="_blank">https://wiki.openstack.org/<wbr>wiki/OSSN/OSSN-0076</a><br>
Original LaunchPad Bug : <a href="https://bugs.launchpad.net/ossn/+bug/1545092" rel="noreferrer" target="_blank">https://bugs.launchpad.net/<wbr>ossn/+bug/1545092</a><br>
OpenStack Security ML : <a href="mailto:openstack-security@lists.openstack.org">openstack-security@lists.<wbr>openstack.org</a><br>
OpenStack Security Group : <a href="https://launchpad.net/~openstack-ossg" rel="noreferrer" target="_blank">https://launchpad.net/~<wbr>openstack-ossg</a><br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><div><span style="color:rgb(136,136,136);font-size:12.8000001907349px">--</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px"><span style="color:rgb(136,136,136);font-size:12.8000001907349px">Kurt Seifried -- Red Hat -- Product Security -- Cloud</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px"><span style="color:rgb(136,136,136);font-size:12.8000001907349px">PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993</span><br style="color:rgb(136,136,136);font-size:12.8000001907349px"><span style="color:rgb(136,136,136);font-size:12.8000001907349px">Red Hat Product Security contact: </span><a href="mailto:secalert@redhat.com" style="color:rgb(17,85,204);font-size:12.8000001907349px" target="_blank">secalert@redhat.com</a><br></div></div></div>
</div>