Open Stack

Hi everyone,

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.

Thanks,
Ken

On Wed, Feb 24, 2016, 13:01  <openstack-security-request at lists.openstack.org>
wrote:

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