Skip to content

Improve description of what is considered a security issue #147035

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jul 17, 2025
Merged

Improve description of what is considered a security issue #147035

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6428a93
Improve description of what is considered a security issue
kbeyls Jul 4, 2025
e6a439e
Address review feedback
kbeyls Jul 7, 2025
ea0d98f
Removing recommendation about use of external sandbox
kbeyls Jul 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 21 additions & 19 deletions llvm/docs/Security.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -157,6 +157,7 @@ Members of the LLVM Security Response Group are expected to:
* Help write and review patches to address security issues.
* Participate in the member nomination and removal processes.

.. _security-group-discussion-medium:

Discussion Medium
=================
Expand Down Expand Up @@ -204,10 +205,9 @@ The LLVM Security Policy may be changed by majority vote of the LLVM Security Re
What is considered a security issue?
Copy link
Member

@gburgessiv gburgessiv Jul 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if it would be helpful to add a concise tl;dr here?

**tl;dr**: Generally speaking, most security issues will be focused on
_a bug or deficiency in LLVM tooling_ that leads to an increased attack
surface in _artifacts produced by said tooling_. Moreover, a buffer
overflow in well-defined usage of libcxx is very likely to be a security
issue, as this defect may lead to vulnerabilities in well-formed code that
uses libcxx. An arbitrary buffer overflow in Clang's frontend is less likely
to be considered a security issue, as the most likely outcome is that it
leads to a Clang crash, which most often just leads to a build failure.

Admittedly, "artifacts" isn't as precise as I'd like it to be, but maybe a bit of iteration on ^ can help us set the tone for this section?

Copy link
Contributor

@wphuhn-intel wphuhn-intel Jul 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO this is too specific for a tl;dr section.

I'm also not wild about calling out artifacts, since I wouldn't consider LLVM runtimes to be "artifacts" of LLVM but part of it (putting aside the obvious technicality of LLVM being used to build LLVM), yet we very clearly mention that LLVM runtimes are in scope if they're intended to be consumed by downstream users.

I'd focus on the intended user since I see that as the main distinguisher throughout this document, something along the lines of "issues with LLVM that affect developers who consciously chose to use LLVM tooling to generate binaries are considered out-of-scope, issues with LLVM which affect the end users of said developer are in scope."

Copy link
Member

@gburgessiv gburgessiv Jul 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm not strongly of the opinion that a tldr is necessary, so I'm also content if we'd rather go without.

In any case, I do agree that intended user is a much better focus than 'artifacts' - thanks for that. :)

Copy link
Collaborator Author

@kbeyls kbeyls Jul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I quite like the sentence that @wphuhn-intel suggested above as a general principle: "issues with LLVM that affect developers who consciously chose to use LLVM tooling to generate binaries are considered out-of-scope, issues with LLVM which affect the end users of said developer are in scope." That being said, I'm not sure if it would correctly cover all the different cases we do document further in detail.

I'd prefer to land this PR without a tl;dr, as is.
We can then see what the feedback is on the this version of the documentation, and add a well-thought-through tl;dr if the feedback is clear that that would be a major improvement.

====================================

Below, with "security-sensitive", we mean that a discovered bug or vulnerability
that might enable an exploit, may require coordinated disclosure, and therefore
should be reported to the LLVM Security Response group rather than publishing in
the public bug tracker.
We define "security-sensitive" to mean that a discovered bug or vulnerability
may require coordinated disclosure, and therefore should be reported to the LLVM
Security Response group rather than publishing in the public bug tracker.

The LLVM Project has a significant amount of code, and not all of it is
considered security-sensitive. This is particularly true because LLVM is used in
Expand All @@ -223,15 +223,11 @@ community as for any RFC. In some cases, parts of the codebase could be handled
as security-sensitive but need significant work to get to the stage where that's
manageable. The LLVM community will need to decide whether it wants to invest in
making these parts of the code securable, and maintain these security properties
over time. In all cases the LLVM Security Response Group should be consulted,
since they'll be responding to security issues filed against these parts of the
codebase.
over time. In all cases the LLVM Security Response Group
`should be consulted <security-group-discussion-medium_>`__, since they'll be
responding to security issues filed against these parts of the codebase.

The security-sensitive parts of the LLVM Project currently are the following.
Note that this list can change over time. If you're not sure whether an issue is
in-scope for this security process or not, err towards assuming that it is. The
Security Response Group might agree or disagree and will explain its rationale
in the report, as well as update this document through the above process.
The security-sensitive parts of the LLVM Project currently are the following:

* Code generation: most miscompilations are not security sensitive. However, a
Copy link
Collaborator

@smithp35 smithp35 Jul 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could be worth going into a bit more detail here. Otherwise I expect something like, miscompile causes a segfault leading to denial of service attack. I think we would be looking for something systemic that affected multiple programs in a predictable way that an attacker could exploit.

I've found it difficult to think of concrete examples:

  • Major mitigation bypasses
  • Breaking security properties of certain attributes like cmse_nonsecure_call

Copy link
Collaborator Author

@kbeyls kbeyls Jul 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it would be nice if we could be more concrete in the description here.
Given we've seen very few (I can think of one) such cases, I find it hard to describe very clearly what would be considered a security-sensitive code generation bug and what wouldn't. I think I'd prefer to leave it a bit more vague. If the security group does end up getting quite a few code generation-related reports, we could use those example and our experience with analyzing them to refine the text further?

Copy link
Contributor

@wphuhn-intel wphuhn-intel Jul 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm inclined to lean into the existence (or credible plausibility of existance) of a reproducer being the key distinguisher here, i.e. leave the text as is.

Even in "obviously" security-implicated features like compiler hardening techniques, most software bugs realistically will not reduce the security of the customer's executable beyond a handwave-y DoS argument. (Yes, I'm aware there's an A in CIA, but in my opinion the security community has gone way overboard in classifying every potential process crash as a CVE, and I don't think I'm alone in this assessment.)

I've also seen cases (not in LLVM) where a "ordinary" miscompilation bug was systematically reproducible in security-critical code, such that it necessitated a security response despite being seemingly benign.

I think it's still a good idea for issues @smithp35 mentioned to be run by us, because there is an elevated risk that they could lead to an actual security vulnerability, but at the same time I don't want to give security researchers the impression that these sections of the code must automatically entitle them to a CVE they can slap on their CVs.

Copy link
Collaborator Author

@kbeyls kbeyls Jul 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the interesting discussion on this!
My opinion is that we probably should publish the text as is, and iterate/improve it, if needed, later, based on further experience.

miscompilation where there are clear indications that it can result in the
Expand All @@ -241,17 +237,17 @@ in the report, as well as update this document through the above process.
security-sensitive. The parts that are not considered security-sensitive are
documented below.

The parts of the LLVM Project which are currently treated as non-security
sensitive are the following. Note that this list can change over time.
The following parts of the LLVM Project are currently treated as non-security
sensitive:

* LLVM's language frontends, analyzers, optimizers, and code generators for
which a malicious input can cause undesirable behavior. For example, a
maliciously crafted C, Rust or bitcode input file can cause arbitrary code
to execute in LLVM. These parts of LLVM haven't been hardened, and handling
maliciously crafted C, Rust or bitcode input file can cause arbitrary code to
execute in LLVM. These parts of LLVM haven't been hardened, and handling
untrusted code usually also includes running utilities such as make which can
more readily perform malicious things. For example, vulnerabilities in
clang, clangd, or the LLVM optimizer in a JIT caused by untrusted inputs are
outside of the scope. We recommend the use of an external sandbox in those
more readily perform malicious things. For example, vulnerabilities in clang,
clangd, or the LLVM optimizer in a JIT caused by untrusted inputs are not
security-sensitive. We recommend the use of an external sandbox in those
cases.
* The following parts of the run-time libraries are explicitly not considered
security-sensitive:
Expand All @@ -268,6 +264,12 @@ sensitive are the following. Note that this list can change over time.
against malformed or malicious unwind or exception handling data. This is
not considered security sensitive.

Note that both the explicit security-sensitive and explicit non-security
sensitive lists can change over time. If you're not sure whether an issue is
in-scope for this security process or not, err towards assuming that it is. The
Security Response Group might agree or disagree and will explain its rationale
in the report, as well as update this document through the above process.

.. _CVE process: https://cve.mitre.org
.. _report a vulnerability: https://github.com/llvm/llvm-security-repo/security/advisories/new
.. _llvm/llvm-security-repo: https://github.com/llvm/llvm-security-repo/security
Expand Down
Loading