TL;DR
Shielder, with OSTIF and Amazon Web Services, performed a Security Audit on a subset of the Boost C++ libraries. The audit resulted in five (5) findings ranging from low to medium severity plus two (2) informative notices. The Boost maintainers of the affected libraries addressed some of the issues, while some other were acknowledged as accepted risks.
Today, we are publishing the full report in our dedicated repository.
Introduction
In December 2023, Shielder was hired to perform a Security Audit of Boost, a set of free peer-reviewed portable C++ source libraries. The audit has been sponsored by Amazon Web Services and facilitated by the Open Source Technology Improvement Fund (OSTIF).
Boost consists of a large number of libraries that implement all kind of functionalities, ranging from asynchronous HTTP servers and clients, to Regex/XML/JSON parsers, to image processing libraries, and many more.
The Boost source code comes as a super project (https://github.com/boostorg/boost) where the base documentation exists along with a list of git submodules in the libs folder (https://github.com/boostorg/boost/tree/master/libs) referencing the repositories of each Boost library.
Context and Scope
The aim of the audit was to assess the overall security posture of Boost, and deep dive on some specific libraries. Based on multiple criteria, the following list of libraries were identified for the scope:
- Boost.Beast
- Boost.DLL
- Boost.Date_Time
- Boost.Filesystem
- Boost.GIL
- Boost.Graph
- Boost.JSON
- Boost.Program_Options
- Boost.Regex
- Boost.String_Algo
- Boost.URL
- Boost.UUID
The scope of this audit is the Boost version 1.83.0 released on August 11, 2023.
Findings Summary and Recommendations
The Shielder team was able to identify five (5) low to medium findings, plus two (2) informative notices.
Moreover, the Shielder team developed 15 new fuzzers that were later merged in OSS-Fuzz. The fuzzers already uncovered new testcases and crashes.
| ID | Vulnerability | Severity | Status |
|---|---|---|---|
| 1 | Boost.Beast CRLF Injection in HTTP Headers | Medium | Open1 |
| 2 | Boost.Regex Stack Overflow via Recursion with Multiple end_line Elements on Regex Creation | Low | Closed |
| 3 | Boost.Regex Stack Overflow via Recursion on Multiple Unions and Capture Groups | Low | Closed |
| 4 | Boost.Regex Stack Overflow via Recursion on Multiple Open Parentheses in Format String | Low | Closed |
| 5 | Boost.Graph Stack Overflow via Recursion with Multiple Subgraphs | Low | Closed |
| 6 | Boost.Graph Assertion in breadth_first_search | Informational | Open2 |
| 7 | Boost.DLL DoS via Uncaught Exceptions / Failed Assertions | Informational | Open3 |
1 For performance and backward-compatibility reasons the sanitization of HTTP headers is responsibility of the developers who implement the library in their projects.
2 The narrow contract design of the Boost.Graph library requires that supplied input is valid.
3 The maintainer recommends to avoid supplying untrusted user-controlled binaries to Boost.DLL.
Shielder team also outlined the following recommendations and long-term security improvements for the Boost project:
- Monitor OSS-Fuzz Reports
- Implement a Vulnerability Disclosure Process
- Implement Supply-Chain Attack Countermeasures
- Improve the Documentation with Security Mechanisms and Assumptions
- Avoid the Abuse of Asserts
If you are a developer using the Boost libraries, the recommendation is to Perform Strict Input Validation before passing the input to Boost functions.
The full details and rationale can be read in the report.
Conclusions
The overall security posture of the Boost project is mature, but it is important to highlight that it strongly varies from library to library.
The most used and popular libraries are mature, structured and have a good degree of code quality, while the less used and less maintained one are considerably less mature. The findings density is higher in the latter type of libraries.
The main threats are caused by a lack of user-input sanitization and by the lack of controls on the level of recursion for sensitive functions.
While some user-input sanitization can be delegated to third-party developers using the Boost libraries, in some other cases it is the Boost library duty to validate input and throw exceptions accordingly. For example, a JSON parsing library requiring the developer to provide only valid JSON input will force the developer to parse such JSON beforehand.
We would like to thanks the Boost maintainers and community - notably Vinnie Falco, Alan de Freitas, John Maddock, Andrey Semashev, Antony Polukhin, and Jeremy Murphy - for the email interactions and for addressing part of the findings.
It was a pleasure for our team to work with OSTIF, Amazon Web Services, and the Boost maintainers.
Pitch 🗣
Did you know OSTIF helps sensitive open-source projects in securing funds to perform security audits? They will also help you in scoping the assessment, finding a trusted partner to perform the analysis, and ensuring full transparency along the way.
P.S. if you need help in setting up fuzzers to discover weird behaviors and vulnerabilities in you projects –> get in touch with us!
如有侵权请联系:admin#unsafe.sh