Mitigation of Metadata Endpoint Vulnerability
Article ID: 297618
Updated On:
Products
Issue/Introduction
As reported in CVE-2016-0896, Link-Local Addresses from 169.254.0.0/16 as specified in RFC 3927 such as the VM instance metadata endpoint 169.254.169.254 used by multiple IaaS providers, including AWS EC2, OpenStack, Microsoft Azure and Google Cloud Platform, is accessible by application containers in default PCF Elastic Runtime installations and may expose sensitive information to application containers.
Environment
Cause
As of PCF Elastic Runtime 1.3.0, application containers have a block-by-default network access policy. To enable network access to application containers, PCF Elastic Runtime 1.3.0 introduced a feature called Application Security Groups (ASGs). ASGs are sets of protocols, destinations, and ports an application container may access, similar to a firewall ruleset.
PCF Elastic Runtime 1.3.0 through PCF Elastic Runtime 1.6.34 and 1.7.12 bind by default an ASG named “all_open” to the default staging and default-running ASG sets, which affect all application containers being staged or that is started, respectively. This default ASG is overly permissive, allowing application containers access to the entire IPv4 address space (0.0.0.0-255.255.255.255). This permissive default ASG was used to prevent disruption of application container network access when upgrading to PCF Elastic Runtime 1.3.0.
The permissive default ASG has the following rule:
[
{
"destination": "0.0.0.0-255.255.255.255",
"protocol": "all"
}
]
Changes in PCF Elastic Runtime 1.6.34, 1.7.12
New installs (those that are upgraded to 1.6.34+ or 1.7.12+ from an earlier version) of PCF Elastic Runtime 1.6.34 and 1.7.12 include a replacement default ASG, “default_security_group” which has the following rules:
[
{
"destination": "0.0.0.0-169.253.255.255",
"protocol": "all"
},
{
"destination": "169.255.0.0-255.255.255.255",
"protocol": "all"
}
]
If you have upgraded from <1.6.34 or <1.7.12, you should expect to still have the all_open security group.
Determining Affectedness
To determine if your PCF deployment is affected by CVE-2016-0896, verify the all_open security group is bound to default-staging and default-running with the cf CLI [2]:
$ cf staging-security-groups … all_open $ cf running-security-groups … all_open
Verify the contents of the all_open security group by running the following:
$ cf security-group all_open
If the all_open security group contains a “destination” which encompasses 169.254.169.254, or another security group with a similar destination is bound to default-staging and default-running, your PCF deployment is impacted by CVE-2016-0896.
Resolution
This article will describe how to create and bind a new default-staging and default-running ASG that blocks access to Link-Local Addresses in the 169.254.0.0/16 CIDR. You need to restart any running applications for ASG changes to take this effect. Any application pushed after the new ASG is bound and the old ASG is unbound will be denied access to 169.254.0.0/16.
In this article, we will:
- Create a new ASG
- Bind the new ASG to the default-staging and default-running ASG sets
- Unbind the existing ASG from the default-staging and default-running ASG sets
- Restart ‘started’ applications in all "orgs" and spaces other than those contained in the system org.
Create a New ASG
Create a new JSON file, default_security_group.json, with the following contents:
[
{
"destination": "0.0.0.0-169.253.255.255",
"protocol": "all"
},
{
"destination": "169.255.0.0-255.255.255.255",
"protocol": "all"
}
]
These ASG rules are the ones that presently ship with Elastic Runtime.
Using the cf CLI, create a new ASG with the rules file created above with the following:
# logged in as an administrator $ cf create-security-group default_security_group default_security_group.json
Bind the new ASG to default-staging and default-running
Using the cf CLI, perform the following steps:
# logged in as an administrator $ cf bind-staging-security-group default_security_group $ cf bind-running-security-group default_security_group
Unbind the old default ASG from both default-staging and default-running
Note- Make sure you have created and bound the new default ASG before proceeding.
Once your new default_security_group ASG is bound to both default-staging and default-running, you can unbind the old default ASG from default-staging and default-running:
$ cf unbind-staging-security-group all_open Unbinding security group all_open from defaults for staging as admin OK $ cf unbind-running-security-group all_open Unbinding security group all_open from defaults for running as admin OK
Restart applications to apply the new ASG:
To restart an application, use the "cf restart" command. When restarting an application it will not be able to receive traffic during the restart. To mitigate the application downtime incurred during a restart, a blue-green [3] deployment strategy is recommended.
To restart applications in bulk, you may choose to use the app-restarter cf CLI plugin [4] to restart all apps in the deployment, only those in a specific organization, or only those in a specific space.
Applications running in the “system” organization are those installed by PCF Elastic Runtime and any Services that have been installed and do not need to be restarted.
Note- Started applications won't have the new default ASG applied to them until they are restarted. Any application pushed after binding the new default ASG will receive the updated ASG automatically.
Feedback
