Hi all,
The LLVM security response group have just published their 2024 transparency report.
I copy pasted the content of the transparency below for ease of reference.
Thanks,
Kristof
LLVM security response group 2024 transparency report
Introduction
In the first half of 2024, LLVM used the Chromium issue tracker to enable reporting security issues responsibly. We switched over to using GitHub’s “privately reporting a security vulnerability” workflow in the middle of 2024.
In previous years, our transparency reports were shorter, since the full discussion on a security ticket in the Chromium issue tracker is fully visible once disclosed. This is not the case with issues using GitHub’s security advisory workflow, so instead we give a longer description in this transparency report, to make the relevant information on the ticket publicly available.
This transparency report doesn’t necessarily mention all issues that were deemed duplicates of other issues, or tickets only created to test the bug tracking system.
Security issues fixed under a coordinated disclosure process
This section lists the reported issues where we ended up implementing fixes under a coordinated disclosure process.
While we were still using the Chromium issue tracker, we did not write security advisories for such issues. Since we started using the GitHub issues tracker for security issues, we’re now publishing security advisories for those issues at https://github.com/llvm/llvm-security-repo/security/advisories/.
- “Unexpected behavior when using LTO and branch-protection together”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=58 - “Security weakness in PCS for CMSE” (CVE-2024-0151)
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=68 - “CMSE secure state may leak from stack to floating-point registers” (CVE-2024-7883)
Details are available at GHSA-wh65-j229-6wfp
Supply chain security related issues and project services-related issues
- “GitHub User Involved in xz backdoor may have attempted to change to clang in order to help hide the exploit”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=71 - “llvmbot account suspended due to supicious login”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=72 - “.git Exposure”
GHSA-mr8r-vvrc-w6rq
The .git directory was accessible via web browsers under apt.llvm.org, a site used to serve Debian/Ubuntu nightly packages. This issue has been addressed by removing the directory, and is not considered a security issue for the compiler. The .git directory was an artifact of the CI job that maintained the apt website, and was mirroring an open-source project maintained on github (under opencollab/llvm-jenkins.debian.net). The issue is not believed to have leaked any non-public information. - “llvm/llvm-project repo potentially vulnerable to GITHUB_TOKEN leaks”
GHSA-f5xj-84f9-mrw6
GitHub access tokens were being leaked in artifacts generated by GitHub Actions workflows. The vulnerability was first reported publicly as ArtiPACKED, generally applicable to GitHub projects, leading to an audit of LLVM projects and the reporting of this security issue. LLVM contributors audited the workflows, found that the “release-binaries” workflow was affected, but only exposed tokens that were ephemeral and read-only, so was not deemed a privilege escalation concern. The workflow was fixed in a configuration change as PR 106310. Older exposed tokens all expired, and the issue is closed as resolved. - “RCE in Buildkite Pipeline”
GHSA-2j6q-qcfm-3wcx
A Buildkite CI pipeline (llvm-project/rust-llvm-integrate-prototype) allowed Remote Code Execution on the CI runner. The pipeline automatically runs a test job when PRs are filed on the rust-lang/rust repo, but those PRs point to user-controlled branches that could be maliciously modified. A security researcher reported the issue, and demonstrated it by modifying build scripts to expose the CI runner’s internal cloud service access tokens. The issue has been addressed with internal configuration changes by owners of the Buildkite pipeline.
Issues deemed to not require coordinated action before disclosing publicly
- “Clang Address Sanitizer gives False Negative for Array Out of Bounds Compiled with Optimization”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=57 - “Found exposed .svn folder”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=59 - “Arbitrary code execution when combining SafeStack + dynamic stack allocations + __builtin_setjmp/longjmp”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=60 - “RISC-V: Constants are allocated in writeable .sdata section”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=61 - “Manifest File with Out-of-Date Dependencies with CVEs”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=62 - “Non-const derived ctor should fail compilation when having a consteval base ctor”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=67 - “Wrong assembly code generation. Branching to the corrupted “LR”.”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=69 - “Security bug report”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=70 - “Using ASan with setuid binaries can lead to arbitrary file write and elevation of privileges”
Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=73 - “Interesting bugs for bool variable in clang projects and aarch64 modes outputting inaccurate results.”
GHSA-w7qc-292v-5xh6
The issue reported is on a source code example having undefined behaviour (UB), somewhat similar to this: https://godbolt.org/z/vo4P7bPYr. Therefore, this issue was closed as not a security issue in the compiler.
As part of the analysis on this issue, it was deemed useful to document this example of UB and similar cases to help users of compilers understand how UB in source code can lead to security issues.
We concluded that probably the best option to do so is to create a regular public issue at https://github.com/llvm/llvm-project/issues, with the same title as the security issue, and to attach a PDF (which should easily be created using a “print-to-pdf” method in the browser) containing all comments. Such public tickets probably need some consistent way to indicate they come from security issues that after analysis were deemed to be outside the LLVM threat model or weren’t accepted as a needs-resolution-work-in-private security issue for other reasons. The LLVM
Security Response group has so far not taken action to progress this idea.
There was also a suggestion of potentially adding a short section in https://llsoftsec.github.io/llsoftsecbook/#compiler-introduced-security-vulnerabilities that summarizes a short example showing that type aliasing UB can and is causing security vulnerabilities. - “llvm-libc qsort can use very large amounts of stack if an attacker can control its input list”
GHSA-gw5j-473x-p29m
If the llvm-libcqsortfunction is used in a context where its input list comes from an attacker, then the attacker can craft a list that causesqsort’s stack usage to be linear in the size of the input array, potentially overflowing the available memory region for the stack.
After discussion with stakeholders, including maintainers for llvm-libc, the conclusion was that this doesn’t have to be processed as a security issue needing coordinated disclosure. An improvement toqsort’s implementation was implemented through pull request https://github.com/llvm/llvm-project/pull/110849 - “VersionFromVCS.cmake may leak secrets in released builds”
GHSA-rcw6-jqvr-fcrx
The LLVM build system may leak secrets of VCS configuration into release builds if the user clones the repo with an https link that contains their username and/or password.
Mitigations were implemented in https://github.com/llvm/llvm-project/pull/105220, https://github.com/llvm/llvm-project/commit/57dc09341e5eef758b1abce78822c51069157869. An issue was raised to suggest one more mitigation to be implemented at https://github.com/llvm/llvm-project/issues/109030.
Invalid issues
The LLVM security group received 5 issues which were created accidentally or were not related to the LLVM project.
The subject lines for these were:
- “Found this in my android”
- “[Not a new security issue] Continued discussion for GHSA-w7qc-292v-5xh6”
- “please delete it.”
- “Please help me to delete it.”
- “llvm code being used in malicious hacking of network and children’s devices”
Furthermore, we had 2 tickets that were created to test the setup and workflow as part of migrating to GitHub’s “security advisory”-based reporting:
- “Test if new draft security advisory gets emailed to LLVM security group”
GHSA-82m9-xvw3-rvpv - “Test that a non-admin can create an advisory (no vulnerability).”
GHSA-34gr-6c7h-cc93
