You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Introduction


 
CloudStack console access is implemented as a AJAX application that can run most of popular browsers on various operating platforms. It inherits common security implications from browser-based platforms. This improvement mainly focuses to improve the security against following attacks

  • URL manipulation
  • replay by reusing a copied URL

Use case


A malicious user uses his/her login to CloudStack system, open a valid console access session to a VM,  the user can use tools to learn the console startup URL, manipulate it to try to gain access to VMs that he/she does not have privilege.

  

Design


 
To authenticate a valid console access, following authentication process will be gone through

1) User requests for a console access to a selected VM, the request is usually sent over HTTPS to CloudStack management server

2) CloudStack management server receives the request, after it has picked an available console proxy VM, it time-stamps the request, encrypts the information into an opaque token and sends an access URL with embedded token back to client browser

3) Client browser opens a console window with the access URL

4) The browser console window is now redirected to the console proxy VM that is selected in step 2

5) console proxy VM initiates the authentication process with management server, the process will be conducted through the secure CloudStack agent/management server channel

6) Management server performs the security check, this includes checking the timestamp mentioned in step 2 (it allows up to 2 minute for the original request to become invalid).

7) If the access is granted, a internal console session to the hypervisor that hosts the VM will be initiated and information will be passed back to Console proxy VM through the same agent/management server Channel

8) Console Proxy bridges the hypervisor session with AJAX session.

Following improvement is added to step 2) and 5)

  • Use 128 bit AES encryption to replace previous 64-bit DES encryption to generate the opaque token mentioned in step 2
  • Use Java SecureRandom class to randomly generate the 128 bit encryption key at per-installation basis

Two hidden configuration variables are added to store the encryption key and IV vector

security.encryption.key

        security.encryption.iv

API/UI changes


None

  • No labels