Eucalyptus does not allow api connection over https

Bug #480783 reported by Nick Barcet on 2009-11-11
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fix Released
chris grzegorczyk
eucalyptus (Ubuntu)
Dustin Kirkland 

Bug Description

It seems to be a security issue that Eucalyptus does not allow API connection to happen over an encrypted connection. Currently API calls occur over http on port 8773. As they carry QueryID/SecretKey in clear, anyone that can sniff the network can gain admin privileges on eucalyptus.

As a side effect, in order for landscape to manage a UEC setup, the following ugly workaround needs to be applied

Tags: uec Edit Tag help
Nick Barcet (nijaba) on 2009-11-11
description: updated
Chris Jones (cmsj) wrote :

A clear issue here is that if Eucalyptus generates its own SSL certificate, the tools accessing it via https won't be able to automatically trust the connection because the cert will be unsigned.

I think a good option would be to have http on 8773 and https on another port if the user has specified a simple configuration option to use a legitimate SSL certificate. This would allow for easy setup on purely private clouds, but also not prevent people from slightly exposing their setup to the internet if they wish to use an external control tool such as Landscape or RightScale.

Thierry Carrez (ttx) on 2009-11-13
Changed in eucalyptus (Ubuntu):
importance: Undecided → High
Kees Cook (kees) wrote :

Is there any reason this should be private?

Changed in eucalyptus (Ubuntu):
status: New → Incomplete
Dustin Kirkland  (kirkland) wrote :

It is a security issue, but does not need to be private. Changing that now...

visibility: private → public
Neil Soman (neilsoman) wrote :

"As they carry QueryID/SecretKey in clear, anyone that can sniff the network can gain admin privileges on eucalyptus."

This assertion is incorrect. The secret is never sent in the clear. A replay attack is possible and its gravity will depend on the specific operation that is replayed.

Chris Jones is correct. There is a workaround for this however which involves explicitly trusting the cert, which depending on the client may or may not be a manual step.

Eucalyptus upstream will fix this in the next release.


On Mon, Nov 16, 2009 at 05:27:37PM -0000, Neil Soman wrote:
> This assertion is incorrect. The secret is never sent in the clear. A
> replay attack is possible and its gravity will depend on the specific
> operation that is replayed.

The hash computed by the client includes a time stamp and a time of
expiry, so it's only vulnerable to a replay attack for a limited time.

Also, the hash is specific to the request (the contents of the request
is part of the hash calculation), so if someone were to intercept it and
try to use it, they would only be able to perform operations the user
already intended to perform. If Eucalyptus were to keep track of hashes
and reject an already seen hash (naturally expiring them as time
passes), this vulnerability should be entirely mitigated, as far as I
can see.

chris grzegorczyk (chris-grze) wrote :

Support for SSL is already in the code as of 1.6.1. The blocker to including it in the original release was client support (as Neil mentioned). This is on the agenda and will be addressed shortly.


Changed in eucalyptus:
assignee: nobody → chris grzegorczyk (chris-grze)
importance: Undecided → Medium
status: New → In Progress
Chris Jones (cmsj) wrote :

Soren: to me the privacy angle is just as important as the security angle. Being unable to replay attacks is great, but leaking information unnecessarily is still sub-optimal.
It sounds like the right things are happening upstream though, thanks!

chris grzegorczyk (chris-grze) wrote :

revno: 1070 [merge]
committer: decker <decker@personal-army>
branch nick: 1.6
timestamp: Tue 2009-11-17 08:45:59 -0800
  enables the StartTLS-like SSL support on port 8773 and includes the trustStore needed by java clients in the
    revno: 1069.1.2
    committer: decker <decker@personal-army>
    branch nick: 1.6
    timestamp: Tue 2009-11-17 06:45:45 -0800
      generate the jsse cacerts keystore needed for java clients w/ SSL.
    revno: 1069.1.1
    committer: decker <decker@personal-army>
    branch nick: 1.6
    timestamp: Tue 2009-11-17 05:39:48 -0800
      enable starttls-like behaviour for the ssl handler

Changed in eucalyptus:
status: In Progress → Fix Committed
Changed in eucalyptus (Ubuntu):
status: Incomplete → In Progress
assignee: nobody → Dustin Kirkland (kirkland)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package eucalyptus - 1.6.1~bzr1083-0ubuntu1

eucalyptus (1.6.1~bzr1083-0ubuntu1) lucid; urgency=low

  [ Dustin Kirkland ]
  * Merge upstream bzr revision 1082; the following bugs have been fixed
    upstream since the last merge:
    - LP: #378969 - private bug
    - LP: #404842 - init script fix
    - LP: #434283 - existing keys should be overwritten unconditionally
    - LP: #445990 - run instance will fail if no kernel or ramdisk specified
    - LP: #447457 - euca_conf --register-sc ... check the number of parameters
    - LP: #449874 - fix incorrect help text (--delete-nodes doesn't exist)
    - LP: #451795 - show registered images in elastic fox
    - LP: #454405 - return correct networkIndex values on describeInstances
    - LP: #456877 - init script fix
    - LP: #456878 - fix for libvirt xen driver
    - LP: #460085 - fix rampart memory leak
    - LP: #461156 - fix authentication problem w/ userdata
    - LP: #461394 - fix multiple concurrent snapshots on the same volume
    - LP: #461444 - fix memory leaks in NC getConsoleOutput and startup_thread
    - LP: #469984 - fix iptables rules issue
    - LP: #477776 - fix query string authentication
    - LP: #480783 - allow api connection over https
    - LP: #482249 - fix "Describe Regions"
    - LP: #484217 - create keypair should return an error if key exists
    - LP: #490623 - parse RFC 1123 formatted datetime
  * debian/control:
    - make all package lists one-per-line (makes changes henceforth more
      readable), sort lists
    - depend on rampart >= 1.3.0-0ubuntu6, which fixes some shared library
      installation issues
  * debian/patches/04-axis2c-1.6.0-rampart-1.3.0.patch: drop this patch,
    since Eucalyptus 1.6.1 natively supports axis2c 1.6.0 now
  * debian/eucalyptus-cloud.install,
    debian/eucalyptus-java-common.install, debian/eucalyptus-sc.install,
    debian/eucalyptus-walrus.install: update static version number strings
    from "1.6-devel" to "1.6.1"; (we should really find a better way to do
  * debian/patches/03-DESTDIR.patch: ported forward for merge
 -- Dustin Kirkland <email address hidden> Tue, 01 Dec 2009 21:09:28 -0600

Changed in eucalyptus (Ubuntu):
status: In Progress → Fix Released
Changed in eucalyptus:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers