Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Fri, 28 Oct 2016 06:16:58 +0000 (UTC)
From: "ASF subversion and git services (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.13012372.1476455320000.114618.1477635418594@Atlassian.JIRA>
In-Reply-To: <JIRA.13012372.1476455320000@Atlassian.JIRA>
References: <JIRA.13012372.1476455320000@Atlassian.JIRA> <JIRA.13012372.1476455320753@arcas>
Subject: [jira] [Commented] (CLOUDSTACK-9544) Account API keys vulnerability
 in Cloudstack with possible privileges escalation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Fri, 28 Oct 2016 06:17:00 -0000


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-9544?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15614454#comment-15614454 ]=20

ASF subversion and git services commented on CLOUDSTACK-9544:
-------------------------------------------------------------

Commit 08b40525955881869340a8ae3b268dea6edd926b in cloudstack's branch refs=
/heads/4.6 from [~marcaurele]
[ https://git-wip-us.apache.org/repos/asf?p=3Dcloudstack.git;h=3D08b4052 ]

CLOUDSTACK-9544: Check access on account trying to generate user API keys

This fixes CVE-2016-6813

Signed-off-by: Marc-Aur=C3=A8le Brothier <m@brothier.org>
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit 158497d68a92ab1e1f864a77371ea1de5c4dc5bb)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>


> Account API keys vulnerability in Cloudstack with possible privileges esc=
alation
> -------------------------------------------------------------------------=
-------
>
>                 Key: CLOUDSTACK-9544
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-954=
4
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the defa=
ult.)=20
>          Components: API
>            Reporter: John Kinsella
>            Assignee: Rohit Yadav
>             Fix For: 4.8.1.1, 4.9.0.1, 4.5.2.2
>
>         Attachments: fix_api_keys.patch
>
>
> Reported by Marc-Aur=C3=A8le Brothier to security@:
> Hello,
> I don't know if you would consider this as a vulnerabilities but I think =
it is one. Currently in all Cloudstack version, any user having access to t=
he API can regenerate API keys for all user except the system one with ID=
=3D1, with the assumptions that he knows the UUID of the user. With the con=
sideration that user knows another user UUID from a privilege domain, the a=
ttacker can change the api key of that user and then get the same access si=
nce he will receive the new key and secret in the API response for that pri=
vileged user. Therefore he can create a privilege account for himself after=
 that call. From there, it's open bar ;-) It's the description of the worst=
 case scenario.
> Other cases would be to access to other accounts data/vm and invalidate a=
pi keys.
> I think it is a vulnerability since the user UUID is not something suppos=
ed to be kept secret, and having the knowledge of this single uuid let you =
access to the ROOT domain pretty easily.
> Human description to reproduce the case:
> Search for a user in the ROOT domain and admin account of your cloudstack=
 installation, and get the ID of a user, but not the admin one, or create a=
 new user in this account.
> Create or use another user from a different account/domain that does not =
have any privileged access, a normal account. Then using the secretkey and =
apikey from the normal user, issue a registerUserKeys id=3D<privileged user=
 uuid> and see that you're getting a new pair of api & secret key.
> The patch is pretty simple and attached to this email, 3 lines to change =
in one class to check the access of the account caller on the account assoc=
iated to the user uuid in the request. The patch has been done on the file =
version on the master branch, and should be very easily back ported to all =
version since the code hasn't changed much in this method.
> I haven't open any PR or bug of course to relate this finding. We will pa=
tch our own cloudstack version (the repo having this fix is private) today,=
 that's all.
> Let me know if you have any questions or for the follow up.
> Kind regards,


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)