OSTIF Boost security audit report

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2024-05-23 22:50:43

Hi,

Recently, a security audit of several Boost libraries has been
conducted. The audited Boost version was 1.83.0. The report is now
published here:

https://ostif.org/boost-audit-complete/
https://ostif.org/wp-content/uploads/2024/05/OSTIF-Boost-Report-PT-v1.4.pdf

In short, the following libraries were audited:

- Boost.Beast (1 medium issue)
- Boost.DLL (1 informational issue)
- Boost.Date_Time
- Boost.Filesystem
- Boost.GIL
- Boost.Graph (1 low and 1 informational issues)
- Boost.JSON
- Boost.Program_Options
- Boost.Regex (3 low issues)
- Boost.String_Algo
- Boost.URL
- Boost.UUID

No critical or high severity issues were identified. Of the 7 identified
issues, 4 are marked as closed, meaning the issues are fixed. The
remaining 3 are open and listed in Boost.Beast (medium), Boost.DLL
(informational) and Boost.Graph (informational).

During audit, several fuzzing harnesses were developed and added to
OSS-Fuzz:

https://github.com/google/oss-fuzz/tree/master/projects/boost

In the report, there were also a few general recommendations given to
improve project security:

- 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

Also, one general recommendation to Boost users:

- Perform Strict Input Validation

You can find more details in the report.

I'd like to emphasize the "Implement Supply-Chain Attack
Countermeasures" part, which basically comes down to signing git tags
and release tarballs. I think, our release process is indeed not very
reliable, let's say, which showed during the past few releases:

- there was instance when different tarballs for the same RC were
generated from different git revisions
- git tags for the release were missing or pointing to a wrong git commit

Also, release tarballs on GitHub don't have hashsums or signatures attached.

https://github.com/boostorg/boost/issues/838

For tarballs on jfrog, thankfully, there are hashsums published in the
release notes. Perhaps, we could also publish .sig files for all
tarballs, and also publish the public key to verify the signature on the
website.

Also, under "Implement a Vulnerability Disclosure Process" it is
suggested to use GitHub Security Advisories[1] as the mechanism for
reporting security issues. I've never used this tool, but perhaps it is
worth enabling for boostorg on GitHub. Emailing library maintainers
privately might not be a very reliable mechanism for such reports, given
that maintainers may become inactive.

[1]:
https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/configuring-private-vulnerability-reporting-for-an-organization