Shared Responsibility Examples: POODLE
3 minute read | Last updated 5-Nov-2014 | 
Cloud, AWS, Trend Micro
Originally posted on the Trend Micro blog.
This is the third post in a short series on the shared responsibility model for security in the AWS Cloud. Please take a couple of minutes to read part 1 and part 2.
POODLE
Another bug with a catchy name, POODLE, is actually an acronym. It stands for “padding oracle on downgrade legacy encryption.”
This bug was discovered by a Bodo Möller, Thai Duong, and Krzysztof Kotowicz at Google. Their paper provides a fantastic breakdown of the technical details of the issue.
TL:DR, POODLE allows a malicious attacker to force the SSL handshake between a client and server to fallback to an earlier, insecure algorithm and then use known exploits to compromise the communications between the two.
This is obviously a serious issue that needed to be patched quickly.
Affected Systems
In the context of the AWS Cloud, affected services are going to CloudFront, Elastic Load Balancers, and any EC2 instances running web servers or services. These services fall into two categories with respect to the shared responsibility model:
Elastic Load Balancers
Offloading SSL to an Elastic Load Balancer (ELB) is a smart idea. Not only does it bear the overhead for SSL connections, but it also simplifies SSL certificate management.
Unfortunately, AWS ELBs were also affected by POODLE.
The good news is that AWS quickly issued a temporary fix that you could implement with no downtime. Simply changing the security policy that defines the SSL negotiation settings offered a temporary fix.
AWS provided clear guidance and a new default policy (ELBSecurityPolicy–2014–10) that resolved the issue.
With this approach, AWS made it simple for you to take action to fix your existing ELB deployments. They also ensured that the issue didn’t spread by making the default for new ELBs a security policy.
CloudFront
Addressing the issue for CloudFront was very similar to the situation with ELBs. There were more edge cases with CloudFront since it offers a richer set of options, but all of the points made above in the ELB section with respect to the division of responsibilities apply here as well.
EC2 Instances
For any EC2 instances running apps or services that were affected, it was entirely your responsibility to adjust your configuration to mitigate the issue (by disabling SSL v3 as a fallback) or by installing any available patch.
One thing to note is the second hat that AWS wears in this case. For Amazon Linux, AWS is the distribution (distro) maintainer. As the distro maintainer, they also issued the relevant patches .
Again, it was your responsibility to install the patches, but AWS helps here as well. The default configuration for Amazon Linux is to install critical patches on first boot and any subsequent reboot.
Shifting Workloads
POODLE illustrates two very different applications of the shared responsibility model for the same issue.
An abstract service like ELB requires a simple configuration change. AWS does all of the heavy lifting here. For an infrastructure service like EC2, the responsibility to address as issue like this one (which is entirely in the OS layer) falls to you as the consumer of the service.
Next week, we’ll look at another popular issue and see how it plays within this model as we seek to understand the ins and outs of its real-world application.
Planning your calendar for #reInvent? Remember to add SEC313, “ Updating Security Operations For The Cloud.” In this talk, I’ll be showing how you can improve your security practice by leveraging features of the AWS Cloud.