2024 Security Group Transparency Report (#132011)

This adds the Security Response Group's transparency report for 2024.

Author: kbeyls

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