Einstein said that our physical theories should be as simple as possible, but not simpler. The same is true of security: security policies should move as fast as possible, but not faster. There is a “speed of light” for security, just as there is for physics. Try to go faster, and bad things happen.
Last week a new release of OpenSSL came out with some patches for a number of low severity issues, and one high severity issue. The latter issue related to a denial of service attack resulting from the build-up of memory allocations if a client continually attempts to renegotiate during an OCSP Status Request extension with an excessively large size.
While this is bad, the consequences of this attack can be mitigated in a number of ways, and let’s face it: good old fashioned DDoS is still the preferred method of attack if a bad guy wants to shut down a website. That means this vulnerability adds an incremental risk on top of what is already a very large problem, rather than opening up an entirely new vector.
So while I don’t disagree with the CVE classification, when the notification came through on Thursday ActiveState didn’t hold up the pending quarterly release of ActivePerl Enterprise to our customers. Getting timely updates with well-tested security is what ActiveState aims to offer, which doesn’t necessarily mean the very latest bits, because with any new release it can take time to identify new bugs that have been introduced.
The OpenSSL community has a really tough job, and any developer who looks at what they are doing will be amazed by how well they do it. libssl is a complex system that has to be robust against the combined ingenuity of all the black hats on the planet while providing seamless and transparent security to billions of people. The developers and testers work hard to get updated bits out as fast as possible, all the time. It’s a delicate balance between shipping iron-clad code and shipping code that is missing patches for known vulnerabilities.
ActiveState adds another layer of security and protection to this process. For Critical vulnerabilities we typically ship fixes to our enterprise customers within 24 hours of the patch being released. But for anything less than Critical, we serve our enterprise customers best by sometimes not simply shipping the latest bits ASAP, because sometimes the best security is provided by going as fast as possible, but not faster.
Title image courtesy of MosterStina on Pixabay.