[ad_1]
A static analysis feature defined to appear in GCC 10, which will detect common programming errors that can lead to security vulnerabilities, has had its first success – it has fixed a exploitable flaw in OpenSSL.
Bernd Edlinger discovered CVE-2020-1967, a denial of service flaw deemed by the OpenSSL team to be a serious risk. It is possible to crash a server or application that uses a vulnerable version of OpenSSL by sending specially crafted messages when configuring a TLS 1.3 connection.
This means that it is possible to disrupt or delete offline HTTPS websites that use a vulnerable version of the encryption library, by sending a prod-of-death. It can also be used by rogue servers to block web browsers and other connecting applications.
OpenSSL is a software library widely used to provide encrypted connections over networks and the Internet. Here is the technical description of the OpenSSL maintainers of the flaw:
The programming error is corrected in version OpenSSL 1.1.1.g: 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 who ship the library must update their packages and send them to users for installation. Matt Caswell and Benjamin Kaduk are credited for performing a more in-depth analysis of the bug before its disclosure this week.
Although the flaw is an irritation – it's not remote code execution, but it can potentially manage servers and applications – programmers may be more interested in how it was discovered. Edlinger attributes the discovery of the bug to the brand new GCC 10 static analysis function. Edlinger ran this tool on the OpenSSL source, and the flaw was revealed in the diagnostic output.
The static analysis function was introduced as a way to check the C code for common exploitable programming blunders during construction, before the binaries are sent to users. He can catch things like double free() calls, use afterfree() calls, memory leaks, etc. C ++ support is in preparation.
Last month, Red Hat tool chain developer David Malcolm, who worked on the functionality, said the goal was to help developers eliminate potentially exploitable vulnerabilities in their code before it is released.
“My thinking here is that it is better to detect problems as soon as the code is written, using the compiler in which the code is written as part of the compile-edit-debug cycle, rather than having an analysis static as an additional tool “on the side” (possibly owner), “it Explain in a technical note detailing the functionality of the analyzer.
“Therefore, it seems useful to have a static parser built into the compiler that can see exactly the same code as the compiler sees – because it East the compiler. “
That the analyzer tool, accessible via the -fanalyzer command line option, has already been shown to be able to catch serious errors in the deployed code will be a good vote of confidence in the functionality.
“I hope the analyzer provides a decent amount of additional verification without being too expensive,” said Malcolm earlier. “I tried to get -fanalyzer to” simply “double the compilation time as a reasonable compromise for additional checks.”
For what it's worth, other tool chains, as Clang-LLVM, include static analysis, although it's good to see it integrated with GCC, which is used to compile a lot of things, including the Linux kernel. This means that we hope that a good number of security bugs will be discovered and eliminated as more programmers migrate to GCC 10 and take out the analyzer for a spin (preferably before the disbelievers using the functionality to develop code). exploitation for harmful purposes.)
The analyzer is available in the master branch of GCC 10 source code. We hope that the functionality will be finalized in time for the official release of version 10, expected this month or next. The latest current version is 9.3. ®
Sponsored:
Office 365 client-to-client migration tips
[ad_2]