OpenSSL Deep Dive - The Good, The Bad and The Not-So-Ugly

The presentation discusses a vulnerability in OpenSSL 3.0 that requires a specific set of circumstances to exploit, limiting its impact. The speaker emphasizes the importance of exploring and testing vulnerabilities to determine their actual risk.

• The vulnerability requires a valid client certificate and occurs during the certificate handshake process
• The affected code is a narrow window in OpenSSL 3.0, limiting the number of potential targets
• The exploit requires a specific alignment of memory, making it difficult to execute
• The speaker encourages a spirit of exploration and experimentation to determine the actual risk of vulnerabilities

The speaker uses the example of a scissorgy, or the alignment of orbital bodies, to illustrate the difficulty of exploiting the vulnerability. They also mention their own experience of exploiting a vulnerability in their own code years ago, which would not have been vulnerable to this particular exploit.

On October 25, OpenSSL notified users that it had found two new vulnerabilities in OpenSSL 3.0.0 through 3.0.6. One of these was apparently “critical” – the same level as the notorious 2014 Heartbleed flaw. That captured everyone’s attention because Heartbleed affected many high-profile organizations, could compromise encrypted information of all kinds, and actually showed up in the wild. It was bad. But by November 1, when OpenSSL released its version 3.0.7 fix, it more clearly understood the two new vulnerabilities and downgraded them to “high” severity. Since AppSec researchers are in the business of scanning servers, applications and APIs for vulnerabilities, we can add value by illuminating why this was done, with a focus on how attackers might try to exploit these flaws – and why they probably can’t.