ESA-11: Denial of Service Vulnerability in Postgres

Eucalyptus Security Advisory
Advisory ID: 
Severity Level: 
Issue Date: 
Last Updated: 
Affected Products: 
Eucalyptus 3.2.x, 3.1.x


The PostgreSQL security team has released a security advisory identifying an argument injection vulnerability in PostgreSQL 9.1. Although the primary privilege escalation vulnerability does not affect Eucalyptus, this vulnerability does make Eucalyptus 3.1 and 3.2 potentially vulnerable to remote Denial of Service attacks. Eucalyptus 3.3.0 resolves this issue and a workaround is available for the earlier versions.


PostgreSQL is used as a primary database by a number of Eucalyptus components to store their metadata and user information. The database is co-located with the Cloud Controller component (CLC) and accepts remote connections. The argument injection vulnerability identified in PostreSQL 9.1 allows remote unauthenticated attackers to corrupt database files and cause the database server to crash and allows remote authenticated users to modify configuration settings and execute arbitrary code. Eucalyptus is not affected by the vulnerability that allows attacks from remote authenticated users because the Postgres database is exclusively used by Eucalyptus components and no other users exists in the database. However, because of this vulnerability, Eucalyptus 3.1 and 3.2 is vulnerable to DoS attacks. Eucalyptus deployments that restrict network access to CLC are potentially less vulnerable than deployments where public access is allowed.


Network access to the TCP port 8777 on CLC should be restricted to connections from the CLC, Walrus, Storage Controller (SC), and VMWareBroker (VB) Eucalyptus components only. In High Availability ( HA) mode, access to port 8777 should be allowed from both primary and secondary components (CLC, Walrus, SC, and VB). If iptables is used to restrict access to the database on the deployments where the CLC is co-located with a Cluster Controller (CC), starting with Eucalyptus 3.2.1, the firewall rules must be stored in /etc/eucalyptus/iptables-preload to be preserved across CC reboots. You must do a clean restart of the CC after adding firewall rules to that file (in HA mode, a clean stop/start is needed for primary and secondary CCs).


Eucalyptus 3.3.0 resolves this issue by upgrading to PostgreSQL 9.1.9.

Please see for instructions on downloading and upgrading to the latest Eucalyptus software.


It was determined that upgrades to Eucalyptus 3.3.0 packages did not always enforce the PostgreSQL 9.1.9 package to be installed. The eucalyptus-cloud package version 3.3.0-0.0.1140 or greater resolves this issue.

Contact and Help

Contact the Eucalyptus Security Team at