[llvm] 9a078a3 - 2024 Security Group Transparency Report (#132011)
via llvm-commits
llvm-commits at lists.llvm.org
Wed Mar 19 09:26:44 PDT 2025
Author: Kristof Beyls
Date: 2025-03-19T16:26:41Z
New Revision: 9a078a372ea69eb2d3f0700dfa14809648e78a88
URL: https://github.com/llvm/llvm-project/commit/9a078a372ea69eb2d3f0700dfa14809648e78a88
DIFF: https://github.com/llvm/llvm-project/commit/9a078a372ea69eb2d3f0700dfa14809648e78a88.diff
LOG: 2024 Security Group Transparency Report (#132011)
This adds the Security Response Group's transparency report for 2024.
Added:
Modified:
llvm/docs/SecurityTransparencyReports.rst
Removed:
################################################################################
diff --git a/llvm/docs/SecurityTransparencyReports.rst b/llvm/docs/SecurityTransparencyReports.rst
index bfa15ab4c484d..3a91ab1a52479 100644
--- a/llvm/docs/SecurityTransparencyReports.rst
+++ b/llvm/docs/SecurityTransparencyReports.rst
@@ -115,3 +115,171 @@ store introduced by LLVM backends, that regressed due to a procedural oversight.
No dedicated LLVM releases were made for any of the above issues.
Over the course of 2023 we had one person join the LLVM Security Group.
+
+2024
+----
+
+.. |br| raw:: html
+
+ <br/>
+
+
+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/.
+
+1. “Unexpected behavior when using LTO and branch-protection together” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=58
+2. “Security weakness in PCS for CMSE”
+ (`CVE-2024-0151 <https://nvd.nist.gov/vuln/detail/CVE-2024-0151>`_) |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=68
+3. “CMSE secure state may leak from stack to floating-point registers”
+ (`CVE-2024-7883 <https://www.cve.org/cverecord?id=CVE-2024-7883>`_) |br|
+ Details are available at
+ `GHSA-wh65-j229-6wfp <https://github.com/llvm/llvm-security-repo/security/advisories/GHSA-wh65-j229-6wfp>`_
+
+Supply chain security related issues and project services-related issues
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+1. “GitHub User Involved in xz backdoor may have attempted to change to clang in order to help hide the exploit” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=71
+2. “llvmbot account suspended due to supicious login” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=72
+3. “.git Exposure” |br|
+ GHSA-mr8r-vvrc-w6rq |br|
+ 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.
+4. “llvm/llvm-project repo potentially vulnerable to GITHUB\_TOKEN leaks” |br|
+ GHSA-f5xj-84f9-mrw6 |br|
+ 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 <https://github.com/llvm/llvm-project/pull/106310>`_. Older exposed
+ tokens all expired, and the issue is closed as resolved.
+5. “RCE in Buildkite Pipeline” |br|
+ GHSA-2j6q-qcfm-3wcx |br|
+ 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
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+1. “Clang Address Sanitizer gives False Negative for Array Out of Bounds Compiled with Optimization” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=57
+2. “Found exposed .svn folder” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=59
+3. “Arbitrary code execution when combining SafeStack \+ dynamic stack allocations \+ \_\_builtin\_setjmp/longjmp” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=60
+4. “RISC-V: Constants are allocated in writeable .sdata section” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=61
+5. “Manifest File with Out-of-Date Dependencies with CVEs” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=62
+6. “Non-const derived ctor should fail compilation when having a consteval base ctor” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=67
+7. “Wrong assembly code generation. Branching to the corrupted "LR".” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=69
+8. “Security bug report” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=70
+9. “Using ASan with setuid binaries can lead to arbitrary file write and elevation of privileges” |br|
+ Details are available at https://bugs.chromium.org/p/llvm/issues/detail?id=73
+10. “Interesting bugs for bool variable in clang projects and aarch64 modes outputting inaccurate results.” |br|
+ GHSA-w7qc-292v-5xh6 |br|
+ 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. |br|
+ 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. |br|
+ 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. |br|
+ 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.
+11. “llvm-libc qsort can use very large amounts of stack if an attacker can control its input list” |br|
+ GHSA-gw5j-473x-p29m |br|
+ If the llvm-libc `qsort` function is used in a context where its input list
+ comes from an attacker, then the attacker can craft a list that causes
+ `qsort`'s stack usage to be linear in the size of the input array,
+ potentially overflowing the available memory region for the stack. |br|
+ 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 to `qsort`'s implementation
+ was implemented through pull request
+ https://github.com/llvm/llvm-project/pull/110849.
+12. “VersionFromVCS.cmake may leak secrets in released builds” |br|
+ GHSA-rcw6-jqvr-fcrx |br|
+ 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. |br|
+ 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:
+
+1. “Test if new draft security advisory gets emailed to LLVM security group” |br|
+ GHSA-82m9-xvw3-rvpv
+2. “Test that a non-admin can create an advisory (no vulnerability).” |br|
+ GHSA-34gr-6c7h-cc93
\ No newline at end of file
More information about the llvm-commits
mailing list