Hi everyone,<div><br></div><div>I was just wondering about this and thought it wise to ask. Asides this list, is there a way to pull openstack security bugs and advisories/reports programmatically maybe in json format ? This feature could be useful for security automation etc.</div><div><br></div><div>Thanks,</div><div>Ken<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 24, 2016, 13:01 <<a href="mailto:openstack-security-request@lists.openstack.org">openstack-security-request@lists.openstack.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Openstack-security mailing list submissions to<br>
<a href="mailto:openstack-security@lists.openstack.org" target="_blank">openstack-security@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security</a><br>
<br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-security-request@lists.openstack.org" target="_blank">openstack-security-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-security-owner@lists.openstack.org" target="_blank">openstack-security-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Openstack-security digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. [Bug 1455582] Re: Hypervisor compromise may result in<br>
malicious trust creation (Dolph Mathews)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 23 Feb 2016 15:00:22 -0000<br>
From: Dolph Mathews <<a href="mailto:1455582@bugs.launchpad.net" target="_blank">1455582@bugs.launchpad.net</a>><br>
To: <a href="mailto:openstack-security@lists.openstack.org" target="_blank">openstack-security@lists.openstack.org</a><br>
Subject: [Openstack-security] [Bug 1455582] Re: Hypervisor compromise<br>
may result in malicious trust creation<br>
Message-ID:<br>
<<a href="mailto:20160223150022.1606.60774.malone@chaenomeles.canonical.com" target="_blank">20160223150022.1606.60774.malone@chaenomeles.canonical.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Closing this because bearer tokens, etc, are a well known weakness.<br>
<br>
** Changed in: keystone<br>
Status: Confirmed => Won't Fix<br>
<br>
--<br>
You received this bug notification because you are a member of OpenStack<br>
Security, which is subscribed to OpenStack.<br>
<a href="https://bugs.launchpad.net/bugs/1455582" rel="noreferrer" target="_blank">https://bugs.launchpad.net/bugs/1455582</a><br>
<br>
Title:<br>
Hypervisor compromise may result in malicious trust creation<br>
<br>
Status in OpenStack Identity (keystone):<br>
Won't Fix<br>
Status in OpenStack Security Advisory:<br>
Won't Fix<br>
Status in OpenStack Security Notes:<br>
Fix Released<br>
<br>
Bug description:<br>
<br>
If a hypervisor is compromised, and the hypervisor is a a Nova compute node, the end user now has access to every token that passes through that node.<br>
<br>
By default, a keystone token can be exchanged for another token. There<br>
is no restriction on scoping of the new token. A scoped token can be<br>
exchanged for an unscoped token, or a token scoped to a different<br>
project.<br>
<br>
We had set the default time limit for tokens down to 1 hour, to reduce<br>
the surface area of the attack. However, many workloads require a<br>
single token for the whole workload, and these workloads take more<br>
than one hour, so several installations have increased token lifespans<br>
back to the old value of 24 hours.<br>
<br>
A token can be used to change a password. If this is done, all tokens<br>
are revoked for the user.<br>
<br>
With the trust API, a user can set up a long term delegation that<br>
allows another user to perform an operation on their behalf. While<br>
tokens created via trusts are limited in what they can do, the<br>
limitations are only on things like change passwords or create a new<br>
token.<br>
<br>
Thus, if an attacker compromises a compute node and harvests tokens,<br>
the highest value attack for them is to automatically create a trust<br>
from the compromised user to some other account. This bypasses the<br>
time limitation of the token expiration, and will allow the attacker<br>
to perform operations on the users resources at the attackers<br>
convenience.<br>
<br>
Any site that is running a recent version of Heat would be expected to<br>
have many trusts set up from the customer user accounts to the Heat<br>
service user. Heat creates trusts using the users tokens, so we know<br>
this approach is not just theoretical, but actively used.<br>
<br>
This leaves a fairly obvious trail, in that a user can see all of the<br>
trusts created with the user as the trustor. Any trusts that do not<br>
have a Heat user as the trustee are suspect. It might even be<br>
possible to compromise Heat users, so even those should be audited.<br>
<br>
There are other ways that a harvested token can be abused, but the<br>
trust approach is the one I find the most worrysome, as it could be<br>
done as a "sleeper" agent.<br>
<br>
The same issues apply to the OAUTH1.0a extension.<br>
<br>
To manage notifications about this bug go to:<br>
<a href="https://bugs.launchpad.net/keystone/+bug/1455582/+subscriptions" rel="noreferrer" target="_blank">https://bugs.launchpad.net/keystone/+bug/1455582/+subscriptions</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Openstack-security mailing list<br>
<a href="mailto:Openstack-security@lists.openstack.org" target="_blank">Openstack-security@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security</a><br>
<br>
<br>
End of Openstack-security Digest, Vol 36, Issue 14<br>
**************************************************<br>
</blockquote></div></div>