Page tree
Skip to end of metadata
Go to start of metadata

Denial of Service Vulnerability in Postgres


 

Description

Denial of Service Vulnerability in Postgres

Severity LevelIMPORTANT
Issue Date2013-04-09
Last Updated2013-07-25
Affected ProductsEucalyptus 3.2.x, 3.1.x
CVE NumberCVE-2013-1899

 

 

Overview

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.

Description

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.

Workaround

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).

Solution

Eucalyptus 3.3.0 resolves this issue by upgrading to PostgreSQL 9.1.9.

Please see https://www.eucalyptus.com/download/eucalyptus for instructions on downloading and upgrading to the latest Eucalyptus software.

Contact and help

Contact the Eucalyptus security team at security@eucalyptus.com.