Demetrius Tsitrelis created CLOUDSTACK-7049:
-----------------------------------------------
Summary: APIs return sensitive information which CloudStack does
not manage and which caller did not request
Key: CLOUDSTACK-7049
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7049
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API
Affects Versions: 4.4.0
Reporter: Demetrius Tsitrelis
Priority: Critical
CloudStack stores sensitive information such as passwords and keys. Some of
this information it creates such as the users’ secret keys. Admins configure
CloudStack with the other types of sensitive information such as host
passwords, S3 secret keys, etc.
There are two problems with the way the API returns sensitive information:
1) Many of the APIs return the entire state of the modified object on
which they operate. For example, if the API to remove a NIC from a VM is
called then the response returns the VM password even though the caller did not
ask for it.
2) Some of the APIs return sensitive information which is not created nor
managed by CloudStack. For instance, the listS3s API returns the S3 secret
key. There doesn’t seem to be any legitimate use case for returning this
category of information; this type of sensitive data could go into CloudStack
for its internal use but should not come out via the API (i.e., CloudStack is
not a password manager app!).
Substantial changes cannot be made to the API without bumping the API version.
A near-term mitigation for these problems then is simply to return empty
strings in the response for the sensitive information which is not requested or
which is not managed by CloudStack. So for the removeNicFromVirtualMachine
API, for instance, return an empty string for the "password" value. A caller
could still use getVMPassword to obtain the password if he needed it since it
is CloudStack which generated the VM password. For the S3 case, ALWAYS return
an empty value for the S3 secret key since that key is managed by Amazon and
not CloudStack.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
