mirror of
https://github.com/llvm/llvm-project.git
synced 2025-04-18 13:46:40 +00:00
285 lines
15 KiB
ReStructuredText
285 lines
15 KiB
ReStructuredText
========================================
|
|
LLVM Security Group Transparency Reports
|
|
========================================
|
|
|
|
This page lists the yearly LLVM Security group transparency reports.
|
|
|
|
2021
|
|
----
|
|
|
|
The :doc:`LLVM security group <Security>` was established on the 10th of July
|
|
2020 by the act of the `initial
|
|
commit <https://github.com/llvm/llvm-project/commit/7bf73bcf6d93>`_ describing
|
|
the purpose of the group and the processes it follows. Many of the group's
|
|
processes were still not well-defined enough for the group to operate well.
|
|
Over the course of 2021, the key processes were defined well enough to enable
|
|
the group to operate reasonably well:
|
|
|
|
* We defined details on how to report security issues, see `this commit on
|
|
20th of May 2021 <https://github.com/llvm/llvm-project/commit/c9dbaa4c86d2>`_
|
|
* We refined the nomination process for new group members, see `this
|
|
commit on 30th of July 2021 <https://github.com/llvm/llvm-project/commit/4c98e9455aad>`_
|
|
* We started writing an annual transparency report (you're reading the 2021
|
|
report here).
|
|
|
|
Over the course of 2021, we had 2 people leave the LLVM Security group and 4
|
|
people join.
|
|
|
|
In 2021, the security group received 13 issue reports that were made publicly
|
|
visible before 31st of December 2021. The security group judged 2 of these
|
|
reports to be security issues:
|
|
|
|
* https://bugs.chromium.org/p/llvm/issues/detail?id=5
|
|
* https://bugs.chromium.org/p/llvm/issues/detail?id=11
|
|
|
|
Both issues were addressed with source changes: #5 in clangd/vscode-clangd, and
|
|
#11 in llvm-project. No dedicated LLVM release was made for either.
|
|
|
|
We believe that with the publishing of this first annual transparency report,
|
|
the security group now has implemented all necessary processes for the group to
|
|
operate as promised. The group's processes can be improved further, and we do
|
|
expect further improvements to get implemented in 2022. Many of the potential
|
|
improvements end up being discussed on the `monthly public call on LLVM's
|
|
security group <https://llvm.org/docs/GettingInvolved.html#online-sync-ups>`_.
|
|
|
|
|
|
2022
|
|
----
|
|
|
|
In this section we report on the issues the group received in 2022, or on issues
|
|
that were received earlier, but were disclosed in 2022.
|
|
|
|
In 2022, the llvm security group received 15 issues that have been disclosed at
|
|
the time of writing this transparency report.
|
|
|
|
5 of these were judged to be security issues:
|
|
|
|
* https://bugs.chromium.org/p/llvm/issues/detail?id=17 reports a miscompile in
|
|
LLVM that can result in the frame pointer and return address being
|
|
overwritten. This was fixed.
|
|
|
|
* https://bugs.chromium.org/p/llvm/issues/detail?id=19 reports a vulnerability
|
|
in `std::filesystem::remove_all` in libc++. This was fixed.
|
|
|
|
* https://bugs.chromium.org/p/llvm/issues/detail?id=23 reports a new Spectre
|
|
gadget variant that Speculative Load Hardening (SLH) does not mitigate. No
|
|
extension to SLH was implemented to also mitigate against this variant.
|
|
|
|
* https://bugs.chromium.org/p/llvm/issues/detail?id=30 reports missing memory
|
|
safety protection on the (C++) exception handling path. A number of fixes
|
|
were implemented.
|
|
|
|
* https://bugs.chromium.org/p/llvm/issues/detail?id=33 reports the RETBLEED
|
|
vulnerability. The outcome was clang growing a new security hardening feature
|
|
`-mfunction-return=thunk-extern`, see https://reviews.llvm.org/D129572.
|
|
|
|
|
|
No dedicated LLVM releases were made for any of the above issues.
|
|
|
|
2023
|
|
----
|
|
|
|
In this section we report on the issues the group received in 2023, or on issues
|
|
that were received earlier, but were disclosed in 2023.
|
|
|
|
9 of these were judged to be security issues:
|
|
|
|
https://bugs.chromium.org/p/llvm/issues/detail?id=36 reports the presence of
|
|
.git folder in https://llvm.org/.git.
|
|
|
|
https://bugs.chromium.org/p/llvm/issues/detail?id=66 reports the presence of
|
|
a GitHub Personal Access token in a DockerHub imaage.
|
|
|
|
https://bugs.chromium.org/p/llvm/issues/detail?id=42 reports a potential gap
|
|
in the Armv8.1-m BTI protection, involving a combination of large switch statements
|
|
and __builtin_unreachable() in the default case.
|
|
|
|
https://bugs.chromium.org/p/llvm/issues/detail?id=43 reports a dependency
|
|
on an old version of xml2js with a CVE filed against it.
|
|
|
|
https://bugs.chromium.org/p/llvm/issues/detail?id=45 reports a number of
|
|
dependencies that have had vulnerabilities reported against them.
|
|
|
|
https://bugs.chromium.org/p/llvm/issues/detail?id=46 is related to issue 43.
|
|
|
|
https://bugs.chromium.org/p/llvm/issues/detail?id=48 reports a buffer overflow
|
|
in std::format from -fexperimental-library.
|
|
|
|
https://bugs.chromium.org/p/llvm/issues/detail?id=54 reports a memory leak in
|
|
basic_string move assignment when built with libc++ versions <=6.0 and run against
|
|
newer libc++ shared/dylibs.
|
|
|
|
https://bugs.chromium.org/p/llvm/issues/detail?id=56 reports an out of bounds buffer
|
|
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 |