cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rohit Yadav (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-7049) APIs return sensitive information which CloudStack does not manage and which caller did not request
Date Tue, 16 Sep 2014 10:21:34 GMT

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14135246#comment-14135246
] 

Rohit Yadav commented on CLOUDSTACK-7049:
-----------------------------------------

Every API since at least 4.3.0 has a requestHasSensitiveInfo and responseHasSensitiveInfo
which can be set to true suitably to make sure CloudStack does not leak sensitive output in
logs. As far as individual API is concerned, what you've presented is a very valid issue but
can you share or list APIs which do that so we can have a look and fix them? Historically,
we kept adding stuff to the API to suit the needs of the UI so we don't have very clean RESTful
API implementation.

> 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
>              Labels: security
>
> 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.3.4#6332)

Mime
View raw message