[ https://issues.apache.org/jira/browse/CLOUDSTACK-9544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614447#comment-15614447 ]
ASF subversion and git services commented on CLOUDSTACK-9544: ------------------------------------------------------------- Commit ec1d1e50c5bdea785fd5784700b47d561830ff46 in cloudstack's branch refs/heads/4.8 from [~rohit.ya...@shapeblue.com] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ec1d1e5 ] Merge pull request #1742 from shapeblue/cve-2016-6813 CLOUDSTACK-9544: Check access on account trying to generate user API keysThis is to merge Marc's fix on 4.8+ branches. Tests run: $ nosetests --with-xunit --xunit-file=test-results.xml --with-marvin --marvin-config=../marvin-cfgs/adv-kvm.cfg -s -a tags=role --zone=Sandbox-simulator --hypervisor=Simulator test/integration/component/test_accounts.py ==== Marvin Init Started ==== === Marvin Parse Config Successful === === Marvin Setting TestData Successful=== ==== Log Folder Path: /tmp//MarvinLogs//Oct_27_2016_22_44_32_GVC833. All logs will be available here ==== === Marvin Init Logging Successful=== ==== Marvin Init Successful ==== === TestName: test_user_cannot_renew_other_keys | Status : SUCCESS === === TestName: test_user_key_renew_same_account | Status : SUCCESS === === TestName: test_updateAdminDetails | Status : SUCCESS === === TestName: test_updateDomainAdminDetails | Status : SUCCESS === === TestName: test_updateUserDetails | Status : SUCCESS === ===final results are now copied to: /tmp//MarvinLogs/test_accounts_90CDC2=== * pr/1742: CLOUDSTACK-9544: Check access on account trying to generate user API keys Signed-off-by: Rohit Yadav <rohit.ya...@shapeblue.com> > Account API keys vulnerability in Cloudstack with possible privileges > escalation > -------------------------------------------------------------------------------- > > Key: CLOUDSTACK-9544 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9544 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > 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èle 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 the > API can regenerate API keys for all user except the system one with ID=1, > with the assumptions that he knows the UUID of the user. With the > consideration that user knows another user UUID from a privilege domain, the > attacker can change the api key of that user and then get the same access > since he will receive the new key and secret in the API response for that > privileged 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 api > keys. > I think it is a vulnerability since the user UUID is not something supposed > 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=<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 associated > 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 patch > 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)