GCC 10 gets security bug trap. And look what just fell into it: OpenSSL and a prod-of-death flaw in servers and apps

April 23, 2020 TH Author

A static analysis feature set to appear in GCC 10, which will catch common programming errors that can lead to security vulnerabilities, has scored an early win – it snared an exploitable flaw in OpenSSL.

Bernd Edlinger discovered CVE-2020-1967, a denial-of-service flaw deemed to be a high severity risk by the OpenSSL team. It is possible to crash a server or application that uses a vulnerable build of OpenSSL by sending specially crafted messages while setting up a TLS 1.3 connection.

This means it’s possible to disrupt or knock offline HTTPS websites that use a vulnerable version of the crypto library, by sending a prod-of-death. It can also be used by rogue servers to crash web browsers and other apps connecting in.

OpenSSL is a software library widely used to provide encrypted connections across networks and the internet. Here’s the technical description from the OpenSSL maintainers of the flaw:

The programming blunder is fixed in the OpenSSL 1.1.1.g release: versions 1.1.1d, 1.1.1e, and 1.1.1f are affected. Users with buggy versions installed are advised to upgrade as soon as possible. Developers shipping the library should update their packages and push them to users to install. Matt Caswell and Benjamin Kaduk are credited for performing further analysis of the bug prior to its disclosure this week.

While the flaw is an irritation – it’s not remote-code execution but it can potentially hose servers and apps – programmers may be more interested in how it was uncovered. Edlinger credits the discovery of the bug to GCC 10’s brand new static analysis feature. Edlinger ran that tool over the OpenSSL source, and the flaw was revealed in diagnostic output.

The static analysis feature was introduced as a way to check C code for common exploitable programming gaffes during build time, before any binaries are shipped to users. It can catch things like double free() calls, use-after-free() calls, memory leaks, and so on. C++ support is said to be in the works.

Last month, Red Hat toolchain developer David Malcolm, who worked on the feature, said the aim was to help developers iron out potentially exploitable vulnerabilities in their code prior to release.

“My thinking here is that it’s best to catch problems as early as possible as the code is written, using the compiler the code is written in as part of the compile-edit-debug cycle, rather than having static analysis as an extra tool ‘on the side’ (perhaps proprietary),” he explained in a technical memo that details the analyzer’s features.

“Hence, it seems worthwhile to have a static analyzer built into the compiler that can see exactly the same code as the compiler sees — because it is the compiler.”

That the analyzer tool, accessed through the -fanalyzer command-line option, has already been shown to be capable of catching serious errors in deployed code will be a nice vote of confidence in the feature.

“My hope is that the analyzer provides a decent amount of extra checking while not being too expensive,” Malcolm said earlier. “I’ve aimed for -fanalyzer to ‘merely’ double the compile time as a reasonable trade-off for the extra checks.”

For what it’s worth, other toolchains, such as Clang-LLVM, feature static analysis, though it’s good to see it built into GCC, which is used to compile a huge number of things, not least the Linux kernel. That means hopefully a good number of security bugs out there will be discovered and squashed as more programmers migrate to GCC 10 and take the analyzer out for a spin (preferably ahead of miscreants using the feature to develop exploit code for nefarious purposes.)

The analyzer is available from the master branch of the GCC 10 source code. It’s hoped the feature will be finalized in time for version 10’s official release, due this month or next. The current latest version is 9.3. ®

Sponsored: Practical tips for Office 365 tenant-to-tenant migration