OpenSSL Vulnerability: In The Fast Lane, Reinforce Your Windshield
If you know that somebody is going to throw a stone at your car’s windshield, then the glass thickness should be proportional to your driving speed (simple physics…).
A parable to container environments: the faster the deployment cycle, the greater the chance that you will pick up a deadly vulnerability, the better should your controls be to discover those vulnerabilities in your environment.
Last week, OpenSSL released an emergency security update that fixes vulnerabilities caused by patches included in their previous security update, released on 22nd September 2016, just 4 (!) days beforehand.
One of those vulnerabilities found by Robert Swiecki (@robertswiecki), an Information Security Engineer at Google, CVE-2016-6309, is a classic use-after-free vulnerability. It has a perfect score of 10, and is the reason for that advisory.
As the advisory states:
The patch applied to address CVE-2016-6307 resulted in an issue where if a message larger than approx 16k is received then the underlying buffer to store the incoming message is reallocated and moved. Unfortunately a dangling pointer to the old location is left, which results in an attempt to write to the previously freed location. This is likely to result in a crash, however it could potentially lead to execution of arbitrary code.
Any containers running with OpenSSL 1.1.0a, released on 22nd September 2016, are affected and should be rebuilt to use OpenSSL 1.1.0b. Given the fast pace of container environments, and the widespread use of OpenSSL in open source and in general, there is a good chance the vulnerable version (a) was picked up in the 4 day gap until version (b) was released.
A malicious actor having network access to container runtime environments could easily DoS all services running with the affected OpenSSL version. After all, the ‘complexity’ is ‘Low’...
New and critical vulnerabilities are revealed every day, and in a fast-changing container-driven environment it is a tremendous challenge to be kept informed and maintain visibility into which container images are vulnerable, how severely, and where vulnerable containers are running.
Organizations should integrate image scanning as part of their CI/CD pipeline to minimize the chances of vulnerable images being pushed into registry without DevOps and Security teams being aware.
Runtime security controls are equally as important, to provide visibility into runtime, and provide automatic controls over the allowed risk level of running containers.
The recent OpenSSL update also fixed the CVE-2016-7052 vulnerability:
A bug fix which included a CRL sanity check was added to OpenSSL 1.1.0 but was omitted from OpenSSL 1.0.2i. As a result any attempt to use CRLs in OpenSSL 1.0.2i will crash with a null pointer exception.
This vulnerability only affects OpenSSL 1.0.2i, released on 22nd September 2016. Any image having that version should be rebuilt to use 1.0.2j.