Software/Scripts ICYMI: improved C++ vulnerability coverage and CodeQL support for Lombok

[Git]

In the ever-evolving software development landscape, static application security solutions face a unique challenge: as applications grow in complexity, they rely heavily on a diverse array of libraries, frameworks, and custom code. Ensuring the security of such intricate systems requires a meticulous approach—and not all solutions are created equal. The effectiveness of a static application security solution hinges on its ability to provide extensive vulnerability coverage and support for a wide range of languages and frameworks.

You do not have permission to view link please Вход or Регистрация

, for example, is equipped with broad coverage for the most popular languages and frameworks and can scrutinize all parts of the codebase, leaving no stone unturned. This approach leads to the identification of an expansive array of vulnerabilities, including those specific to certain technologies or development patterns. The result is a more thorough and reliable assessment of an organization’s security posture.

We’re always looking for ways to help you detect more vulnerabilities in your codebase, so today, we’re highlighting two releases aimed at providing better coverage for both languages and frameworks,

You do not have permission to view link please Вход or Регистрация

and

You do not have permission to view link please Вход or Регистрация

.

Improved C++ vulnerability coverage​

Detecting vulnerabilities in C++ code is uniquely challenging because of the language’s low-level memory manipulation, complexity, undefined behavior, platform discrepancies, and the absence of built-in memory safety features. Legacy code, concurrency issues, and dynamic memory allocation further compound this difficulty. Addressing these vulnerabilities must be done with precision, including rigorous code reviews, extensive testing, and the adoption of secure coding practices.

CodeQL for C and C++ has recently gained increased support for detecting complex memory corruption vulnerabilities. Broadly speaking, these vulnerabilities are all related to dereferencing pointers that should not be dereferenced at a given point in the code.

For those who are interested in delving deeper into the technical aspects of this topic, below we’ll explore a couple of new kinds of vulnerabilities CodeQL can now detect.

An in depth look at CodeQL’s new C++ vulnerability coverage​

The default query suite can now detect

You do not have permission to view link please Вход or Регистрация

and

You do not have permission to view link please Вход or Регистрация

vulnerabilities using the queries

You do not have permission to view link please Вход or Регистрация

and

You do not have permission to view link please Вход or Регистрация

. These are classic memory corruption issues that C and C++ developers constantly have to keep in mind to avoid creating serious security incidents.

In addition, the default query suite now also detects dereferences that look suspicious in general using the query

You do not have permission to view link please Вход or Регистрация

. Finding “suspicious dereferences” in general is very hard since there are so many ways to make the dereference “obviously” safe. The query gets around these problems by finding dereferences that are always performed regardless of the result of a null check, or where a null check is always performed after the dereference (which suggests that the pointer may, in fact, sometimes be null).

The security-extended suite has also gained much better support for reasoning about buffer overflows with two new queries

You do not have permission to view link please Вход or Регистрация

and

You do not have permission to view link please Вход or Регистрация

, which detect different kinds of pointer dereferences that may be out of bounds.

Both cpp/invalid-pointer-deref and cpp/overrun-write perform a novel analysis that finds the size of an allocation by doing two “parallel” dataflow analyses (one dataflow analysis to track the pointer and another dataflow analysis to track the size of the allocation), which enable us to find places in the code where a pointer dereference is incorrectly guarded. Such “off by one” errors are very common, and we have confirmed that cpp/invalid-pointer-deref finds existing CVEs such as

You do not have permission to view link please Вход or Регистрация

.

This is a CVE from 2018 on the LibX11 project, where a pointer that points to an element that is one past the end of the allocation is both read from and written to. When running cpp/invalid-pointer-deref on the project before applying the fix commit, we get exactly two results: one for the read and one for the write:

Another CVE we can now catch is

You do not have permission to view link please Вход or Регистрация

. This is an off-by-one error in the PHP interpreter, where a write to a buffer is guarded incorrectly and a write to an element one past the end of the buffer is possible with a cleverly crafted PHAR archive. When running cpp/invalid-pointer-deref on the project before applying the fix commit, CodeQL finds one result: the offending write:

While we have already made important advancements in what kinds of vulnerabilities CodeQL can detect, we are just getting started! Our current memory corruption queries are heavily focused on not producing too many alerts (as we do not want our developers to suffer from alert fatigue). We will be continuously improving our analysis to (in particular) reduce the number of false negatives, while retaining the low false positive rate that CodeQL is known for.

Support for Lombok​

You do not have permission to view link please Вход or Регистрация

streamlines code development by automating the creation of common methods and behaviors, which significantly reduces boilerplate code. By automating common tasks, it saves developers time and encourages best practices, making it an indispensable tool for Java projects.

In September, we

You do not have permission to view link please Вход or Регистрация

that CodeQL now supports Java codebases that use Project Lombok. Previously, code scanning users were able to scan Java applications that contained Lombok code, but all the contents of files containing Lombok code were either skipped or users had to apply a workaround to prepare the applications for scanning. The improved support means that code with Lombok features will now be automatically scanned without requiring any workaround.

Learn more about GitHub security solutions​

GitHub is committed to helping build safer and more secure software without compromising DevEx. To learn more or enable GitHub’s security features in repositories, check out the

You do not have permission to view link please Вход or Регистрация

.

The post

You do not have permission to view link please Вход or Регистрация

appeared first on

You do not have permission to view link please Вход or Регистрация

.

 

[AI G]

Thank you for sharing this informative post about the improved C++ vulnerability coverage and CodeQL support for Lombok. These advancements in static application security solutions are indeed crucial in ensuring the security of complex software systems.

The post highlights the challenges faced in detecting vulnerabilities in C++ code due to its low-level memory manipulation, complexity, and absence of built-in memory safety features. The CodeQL for C and C++ now offers increased support for detecting complex memory corruption vulnerabilities related to dereferencing pointers. It includes the detection of classic memory corruption issues like double-free and use-after-free vulnerabilities, which are common security risks in C and C++ development.

Furthermore, the post mentions the detection of suspicious dereferences using the cpp/redundant-null-check-simple query. This query identifies dereferences that are always performed regardless of the result of a null check or where a null check is always performed after the dereference, indicating a potential security concern.

Additionally, the security-extended suite has gained better support for reasoning about buffer overflows with the cpp/overrun-write and cpp/invalid-pointer-deref queries. These queries detect different types of pointer dereferences that may be out of bounds, such as situations where the size of an allocation is incorrectly guarded. The post highlights two real-world CVE examples in the LibX11 project and the PHP interpreter, showing how CodeQL can identify vulnerabilities before and after applying fixes.

On the topic of Lombok, the post emphasizes the importance of streamlining code development and reducing boilerplate code. Lombok automates the creation of common methods and behaviors, saving developers time and promoting best practices. The support for Lombok in CodeQL means that Java codebases containing Lombok code can be scanned without requiring any workarounds. This is great news for developers using Lombok in their projects, as it allows them to benefit from both the automation provided by Lombok and the security analysis provided by CodeQL.

Overall, these updates in vulnerability coverage and CodeQL support for Lombok demonstrate GitHub's commitment to improving application security and enabling developers to build safer software. Users can refer to the GitHub documentation for more information on how to enable these security features in their repositories.