Skip to content

Commit 145b6cd

Browse files
authored
Improve description of what is considered a security issue (#147035)
This patch improves the description of what the LLVM project considers a security issue, and what not. This patch is based on the RFC discussion in https://discourse.llvm.org/t/improving-documentation-of-what-is-considered-a-security-issue-in-llvm/86714
1 parent 2b3a410 commit 145b6cd

File tree

1 file changed

+51
-25
lines changed

1 file changed

+51
-25
lines changed

llvm/docs/Security.rst

Lines changed: 51 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -157,6 +157,7 @@ Members of the LLVM Security Response Group are expected to:
157157
* Help write and review patches to address security issues.
158158
* Participate in the member nomination and removal processes.
159159

160+
.. _security-group-discussion-medium:
160161

161162
Discussion Medium
162163
=================
@@ -204,6 +205,10 @@ The LLVM Security Policy may be changed by majority vote of the LLVM Security Re
204205
What is considered a security issue?
205206
====================================
206207

208+
We define "security-sensitive" to mean that a discovered bug or vulnerability
209+
may require coordinated disclosure, and therefore should be reported to the LLVM
210+
Security Response group rather than publishing in the public bug tracker.
211+
207212
The LLVM Project has a significant amount of code, and not all of it is
208213
considered security-sensitive. This is particularly true because LLVM is used in
209214
a wide variety of circumstances: there are different threat models, untrusted
@@ -217,31 +222,52 @@ security-sensitive). This requires a rationale, and buy-in from the LLVM
217222
community as for any RFC. In some cases, parts of the codebase could be handled
218223
as security-sensitive but need significant work to get to the stage where that's
219224
manageable. The LLVM community will need to decide whether it wants to invest in
220-
making these parts of the code securable, and maintain these security
221-
properties over time. In all cases the LLVM Security Response Group should be consulted,
222-
since they'll be responding to security issues filed against these parts of the
223-
codebase.
224-
225-
If you're not sure whether an issue is in-scope for this security process or
226-
not, err towards assuming that it is. The Security Response Group might agree or disagree
227-
and will explain its rationale in the report, as well as update this document
228-
through the above process.
229-
230-
The security-sensitive parts of the LLVM Project currently are the following.
231-
Note that this list can change over time.
232-
233-
* None are currently defined. Please don't let this stop you from reporting
234-
issues to the LLVM Security Response Group that you believe are security-sensitive.
235-
236-
The parts of the LLVM Project which are currently treated as non-security
237-
sensitive are the following. Note that this list can change over time.
238-
239-
* Language front-ends, such as clang, for which a malicious input file can cause
240-
undesirable behavior. For example, a maliciously crafted C or Rust source file
241-
can cause arbitrary code to execute in LLVM. These parts of LLVM haven't been
242-
hardened, and compiling untrusted code usually also includes running utilities
243-
such as `make` which can more readily perform malicious things.
244-
225+
making these parts of the code securable, and maintain these security properties
226+
over time. In all cases the LLVM Security Response Group
227+
`should be consulted <security-group-discussion-medium_>`__, since they'll be
228+
responding to security issues filed against these parts of the codebase.
229+
230+
The security-sensitive parts of the LLVM Project currently are the following:
231+
232+
* Code generation: most miscompilations are not security sensitive. However, a
233+
miscompilation where there are clear indications that it can result in the
234+
produced binary becoming significantly easier to exploit could be considered
235+
security sensitive, and should be reported to the security response group.
236+
* Run-time libraries: only parts of the run-time libraries are considered
237+
security-sensitive. The parts that are not considered security-sensitive are
238+
documented below.
239+
240+
The following parts of the LLVM Project are currently treated as non-security
241+
sensitive:
242+
243+
* LLVM's language frontends, analyzers, optimizers, and code generators for
244+
which a malicious input can cause undesirable behavior. For example, a
245+
maliciously crafted C, Rust or bitcode input file can cause arbitrary code to
246+
execute in LLVM. These parts of LLVM haven't been hardened, and handling
247+
untrusted code usually also includes running utilities such as make which can
248+
more readily perform malicious things. For example, vulnerabilities in clang,
249+
clangd, or the LLVM optimizer in a JIT caused by untrusted inputs are not
250+
security-sensitive.
251+
* The following parts of the run-time libraries are explicitly not considered
252+
security-sensitive:
253+
254+
* parts of the run-time libraries that are not meant to be included in
255+
production binaries. For example, most sanitizers are not considered
256+
security-sensitive as they are meant to be used during development only, not
257+
in production.
258+
* for libc and libc++: if a user calls library functionality in an undefined
259+
or otherwise incorrect way, this will most likely not be considered a
260+
security issue, unless the libc/libc++ documentation explicitly promises to
261+
harden or catch that specific undefined behaviour or incorrect usage.
262+
* unwinding and exception handling: the implementations are not hardened
263+
against malformed or malicious unwind or exception handling data. This is
264+
not considered security sensitive.
265+
266+
Note that both the explicit security-sensitive and explicit non-security
267+
sensitive lists can change over time. If you're not sure whether an issue is
268+
in-scope for this security process or not, err towards assuming that it is. The
269+
Security Response Group might agree or disagree and will explain its rationale
270+
in the report, as well as update this document through the above process.
245271

246272
.. _CVE process: https://cve.mitre.org
247273
.. _report a vulnerability: https://github.com/llvm/llvm-security-repo/security/advisories/new

0 commit comments

Comments
 (0)