Sorry for dropping the ball on this one guys, I currently don't have LP
access due to MFA issues!

Luke Hinds <email address hidden> manages the OSSNs and can get this processed
for you quickly.

I haven't CC'd him on this thread as permission should be controlled
through LP but please add him.

-Rob


On Tue, Jul 25, 2017 at 4:38 PM, Zane Bitter <email address hidden> wrote:

> Any progress on the security note? We've released Ocata with the bug
> since this was last discussed, and we're getting close to releasing
> Pike. I'd still like to have the OSSN, but at this point I'd rather have
> the issue fixed.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1649333
>
> Title:
>   Aodh can be used to launder Keystone trusts
>
> Status in Aodh:
>   In Progress
> Status in OpenStack Security Notes:
>   New
>
> Bug description:
>   When adding an alarm action with the scheme trust+http:, Aodh allows
>   the user to provide a trust ID to use to acquire a token with which to
>   make the webhook request. (If no trust ID is provided then Aodh
>   creates a trust internally, in which case there is no issue.) However,
>   Aodh makes no attempt to check that the user creating the alarm is the
>   trustor or has the same rights as the trustor - it doesn't even
>   attempt to check that the trust is for the same project as the alarm.
>
>   The nature of the trust+http: alarm notifier is that it allows the
>   user to obtain a token given the ID of a trust for which Aodh is the
>   trustee, since the URL is arbitrary and not limited to services in the
>   Keystone catalog.
>
>   It is my understanding (though I'm open to correction) that trust IDs
>   are not meant to be secret - i.e. that security should rely on the
>   secrecy of the trustee's credentials, not of the trust ID.
>
>   The current setup requires that the security posture be equivalent to,
>   or even stronger than, that for a bearer token, since the trust ID can
>   be used to obtain a token and it may never expire. (The vulnerability
>   is limited to Aodh though, since it only applies to trusts where Aodh
>   is the trustee.) In principle this *could* be a valid choice, although
>   I personally would disagree with it. In practice, that is not the
>   current security posture - for example, trust IDs are stored
>   unencrypted in the database and routinely logged unobfuscated.
>
>
>   The easiest solution would be to simply disallow users supplying their
> own trust IDs. This may well be feasible - it's likely that in most clouds
> non-admin users will not have the necessary permissions to get the ID of
> the Aodh service user, which is required to create a trust with that user
> as the trustee. Heat does not supply a trust ID in its convenience code for
> setting up an autoscaling alarm. So there are probably no users of this
> feature in the wild.
>
>   To eliminate the vulnerability without eliminating the feature, I
>   believe Aodh would need to check that the user creating the alarm
>   possesses all of the trust privileges - i.e. their token is for the
>   same project ID and they have all of the roles that the trust does.
>   Or, alternatively, check that the user *is* (i.e. has the same user ID
>   as) the trustor.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/aodh/+bug/1649333/+subscriptions
>