<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 18, 2019 at 2:31 PM Robinson, Paul via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_-3807290467246133003WordSection1">
<p class="MsoNormal">One problem with defining away “arbitrary code execution in Clang” as “not security relevant” is that you are inevitably making probably-wrong assumptions about the set of all possible execution contexts.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Case in point: Sony, being on the security-sensitive side these days, has an internal mandate that we incorporate CVE fixes into open-source products that we deliver. As it happens, we deliver some GNU Binutils tools with our PS4 toolchain.
There are CVEs against Binutils, so we were mandated to incorporate these patches. “?” I said, wondering how some simple command-line tool could have a CVE. Well, it turns out, lots of the Binutils code is packaged in libraries, and some of those libraries
can be used by (apparently) web servers, so through some chain of events it would be possible for a web client to induce Bad Stuff on a server (hopefully no worse than a DoS, but that’s still a security issue). Ergo, security-relevant patch in GNU Binutils.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">For *<b>my</b>* product’s delivery, the CVEs would be irrelevant. (Who cares if some command-line tool can crash if you feed it a bogus PE file; clearly not a security issue.) But, for someone
<i>else’s</i> product, it <i>would</i> be a security issue. You can be sure that the people responsible for Binutils dealt with it as a security issue.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">So, yeah, arbitrary code-execution in Clang, or more obviously in the JIT, is a potential security issue. Clangd probably should worry about this kind of stuff too. And we should be ready to handle it that way.</p></div></div></blockquote><div><br>The reality is that clang is a long way from being hardened in that way (pretty much every crash/assertion failure on invalid input is probably a path to arbitrary code execution if someone wanted to try hard enough) & I don't think the core developers are currently able to/interested in/motivated to do the work to meet that kind of need - so I tend to agree with James that it's better that this is clearly specified as a non-goal than suggest some kind of "best effort" behavior here.<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-3807290467246133003WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal">--paulr<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> <b>On Behalf Of
</b>James Y Knight via llvm-dev<br>
<b>Sent:</b> Monday, November 18, 2019 4:51 PM<br>
<b>To:</b> Chris Bieneman <<a href="mailto:chris.bieneman@me.com" target="_blank">chris.bieneman@me.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] LLVM Security Group and Process<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">I think it's great to make a policy for reporting security bugs.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">But first, yes, we need to be clear as to what sorts of things we consider as "security bugs", and what we do not. We need to be clear on this, both for users to know what they should depend on, and for LLVM contributors to know when they
should be raising a flag, if they discover or fix something themselves.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">We could just keep on doing our usual development process, and respond only to
<i>externally-reported</i> issues with the security-response routine. But I don't think that would be a good idea. Creating a process whereby anyone outside the project can report security issues, and for which we'll coordinate disclosure and create backports
and such is all well and good...but if we don't then also do (or at least <i>try</i> to do!) the same for issues discovered and fixed within the community, is there even a point?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">So, if we're going to expand what we consider a security bug beyond the present "effectively nothing", I think it is really important to be a bit more precise about what it's being expanded to.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<p class="MsoNormal">For example, I think it should generally be agreed that a bug in Clang which allows arbitrary-code-execution in the compiler, given a specially crafted source-file, should not be considered a security issue. A bug, yes, but not a security
issue, because we do not consider the use-case of running the compiler in privileged context to be a supported operation. But also the same for parsing a source-file into a clang AST -- which might even happen automatically with editor integration. Seems less
obviously correct, but, still, the reality today. And, IMO, the same stance should also apply to feeding arbitrary bitcode into LLVM. (And I get the unfortunate feeling that last statement might not find universal agreement.)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Given the current architecture and state of the project, I think it would be rather unwise to pretend that any of those are secure operations, or to try to support them as such with a security response process. Many compiler crashes seem
likely to be security bugs, if someone is trying hard enough. If every time such a bug was fixed, it got a full security-response triggered, with embargos, CVEs, backports, etc...that just seems unsustainable. Maybe it would be
<i>nice</i> to support this, but I think we're a long way from there currently.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">However, all that said -- based on timing and recent events, perhaps your primary goal here is to establish a process for discussing LLVM patches to workaround not-yet-public CPU errata, and issues of that nature. In that case, the need
for the security response group is primarily to allow developing quality LLVM patches based on not-yet-public information about other people's products. That seems like a very useful thing to formalize, indeed, and doesn't need any changes in llvm developers'
thinking. So if that's what we're talking about, let's be clear about it.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Mon, Nov 18, 2019 at 2:43 PM Chris Bieneman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hey JF,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks for putting this RFC together. LLVM security issues are very important, and I'm really glad someone is focusing attention here.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I'm generally in agreement with much of what you have proposed. I do have a few thoughts I'd like to bring up.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Having the group appointed by the board seems a bit odd to me. Historically the board has not involved itself technical processes. I'm curious what the board's thoughts are relating to this level of involvement in project direction (I know
you wanted proposal feedback on Phabricator, but I think the role of the board is something worth discussing here).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">My other meta thought is about focus and direction for the group. How do you define security issues?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">To give you where I'm coming from. One of the big concerns I have at the moment is about running LLVM in secure execution contexts, where we care about bugs in the compiler that could influence code generation, not just the code generation
itself. Historically, I believe, the security focus of LLVM has primarily been on generated code, do you see this group tackling both sides of the problem?<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">-Chris<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal">On Nov 15, 2019, at 10:58 AM, JF Bastien via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<h1><span style="font-size:9pt;font-family:HelveticaNeue,serif;font-weight:normal">Hello compiler enthusiasts,</span><u></u><u></u></h1>
<div>
<p class="MsoNormal"><span style="font-family:HelveticaNeue,serif"><u></u> <u></u></span></p>
</div>
<p class="MsoNormal"><span style="font-family:HelveticaNeue,serif">The Apple LLVM team would like to propose that a new a security process and an associated private LLVM Security Group be created under the umbrella of the LLVM project.<br>
<br>
A draft proposal for how we could organize such a group and what its process could be is </span><a href="https://reviews.llvm.org/D70326" target="_blank">available on Phabricator</a><span style="font-family:HelveticaNeue,serif">. The proposal starts with
a list of goals for the process and Security Group, repeated here:<br>
<br>
The LLVM Security Group has the following goals:</span><u></u><u></u></p>
<ol start="1" type="1">
<li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Allow LLVM contributors and security researchers to disclose security-related issues affecting the LLVM project to members of the LLVM community.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Organize fixes, code reviews, and release management for said issues.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Allow distributors time to investigate and deploy fixes before wide dissemination of vulnerabilities or mitigation shortcomings.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Ensure timely notification and release to vendors who package and distribute LLVM-based toolchains and projects.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Ensure timely notification to users of LLVM-based toolchains whose compiled code is security-sensitive, through <a href="https://cve.mitre.org/" target="_blank">the CVE process</a>.</span><u></u><u></u></li></ol>
<p class="MsoNormal"><span style="font-family:HelveticaNeue,serif"><br>
We’re looking for answers to the following questions:</span><u></u><u></u></p>
<ol start="1" type="1">
<li class="MsoNormal">
<u><span style="font-family:HelveticaNeue,serif">On this list</span></u><span style="font-family:HelveticaNeue,serif">: Should we create a security group and process?</span><u></u><u></u></li><li class="MsoNormal">
<u><span style="font-family:HelveticaNeue,serif">On this list</span></u><span style="font-family:HelveticaNeue,serif">: Do you agree with the goals listed in the proposal?</span><u></u><u></u></li><li class="MsoNormal">
<u><span style="font-family:HelveticaNeue,serif">On this list</span></u><span style="font-family:HelveticaNeue,serif">: at a high-level, what do you think should be done differently, and what do you think is exactly right in the draft proposal?</span><u></u><u></u></li><li class="MsoNormal">
<u><span style="font-family:HelveticaNeue,serif">On the Phabricator code review</span></u><span style="font-family:HelveticaNeue,serif">: going into specific details, what do you think should be done differently, and what do you think is exactly right in
the draft proposal?</span><u></u><u></u></li><li class="MsoNormal">
<u><span style="font-family:HelveticaNeue,serif">On this list</span></u><span style="font-family:HelveticaNeue,serif">: to help understand where you’re coming from with your feedback, it would be helpful to state how you personally approach this issue:</span><u></u><u></u></li></ol>
<ol start="5" type="1">
<ol start="1" type="1">
<li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Are you an LLVM contributor (individual or representing a company)?</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Are you involved with security aspects of LLVM (if so, which)?</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Do you maintain significant downstream LLVM changes?</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Do you package and deploy LLVM for others to use (if so, to how many people)?</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Is your LLVM distribution based on the open-source releases?</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">How often do you usually deploy LLVM?</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">How fast can you deploy an update?</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Does your LLVM distribution handle untrusted inputs, and what kind?</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">What’s the threat model for your LLVM distribution?</span><u></u><u></u></li></ol>
</ol>
<p class="MsoNormal"><span style="font-family:HelveticaNeue,serif"><br>
Other open-source projects have security-related groups and processes. They structure their group very differently from one another. This proposal borrows from some of these projects’ processes. A few examples:</span><u></u><u></u></p>
<ul type="disc">
<li class="MsoNormal">
<a href="https://webkit.org/security-policy/" target="_blank"><span style="font-family:HelveticaNeue,serif">https://webkit.org/security-policy/</span></a><u></u><u></u></li><li class="MsoNormal">
<a href="https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md" target="_blank"><span style="font-family:HelveticaNeue,serif">https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md</span></a><u></u><u></u></li><li class="MsoNormal">
<a href="https://wiki.mozilla.org/Security" target="_blank"><span style="font-family:HelveticaNeue,serif">https://wiki.mozilla.org/Security</span></a><u></u><u></u></li><li class="MsoNormal">
<a href="https://www.openbsd.org/security.html" target="_blank"><span style="font-family:HelveticaNeue,serif">https://www.openbsd.org/security.html</span></a><u></u><u></u></li><li class="MsoNormal">
<a href="https://security-team.debian.org/security_tracker.html" target="_blank"><span style="font-family:HelveticaNeue,serif">https://security-team.debian.org/security_tracker.html</span></a><u></u><u></u></li><li class="MsoNormal">
<a href="https://www.python.org/news/security/" target="_blank"><span style="font-family:HelveticaNeue,serif">https://www.python.org/news/security/</span></a><u></u><u></u></li></ul>
<p class="MsoNormal"><span style="font-family:HelveticaNeue,serif">When providing feedback, it would be great to hear if you’ve dealt with these or other projects’ processes, what works well, and what can be done better.<br>
<br>
<br>
I’ll go first in answering my own questions above:</span><u></u><u></u></p>
<ol start="1" type="1">
<li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Yes! We should create a security group and process.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">We agree with the goals listed.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">We think the proposal is exactly right, but would like to hear the community’s opinions.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Here’s how we approach the security of LLVM:</span><u></u><u></u></li></ol>
<ol start="4" type="1">
<ol start="1" type="1">
<li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">I contribute to LLVM as an Apple employee.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">I’ve been involved in a variety of LLVM security issues, from automatic variable initialization to security-related diagnostics, as well as deploying these mitigations to internal codebases.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">We maintain significant downstream changes.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">We package and deploy LLVM, both internally and externally, for a variety of purposes, including the clang, Swift, and mobile GPU shader compilers.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Our LLVM distribution is not directly derived from the open-source release. In all cases, all non-upstream public patches for our releases are available in repository branches at <a href="https://github.com/apple" target="_blank">https://github.com/apple</a>.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">We have many deployments of LLVM whose release schedules vary significantly. The LLVM build deployed as part of Xcode historically has one major release per year, followed by roughly one minor release every 2
months. Other releases of LLVM are also security-sensitive and don’t follow the same schedule.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">This depends on which release of LLVM is affected.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">Yes, our distribution sometimes handles untrusted input.</span><u></u><u></u></li><li class="MsoNormal">
<span style="font-family:HelveticaNeue,serif">The threat model is highly variable depending on the particular language front-ends being considered.</span><u></u><u></u></li></ol>
</ol>
<p class="MsoNormal"><span style="font-family:HelveticaNeue,serif">Apple is involved with a variety of open-source projects and their disclosures. For example, we frequently work with the WebKit community to handle security issues through their process.<br>
<br>
<br>
Thanks,<br>
<br>
JF</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>