<div dir="ltr"><div dir="ltr">On Mon, Nov 18, 2019 at 6:00 PM JF Bastien via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Nov 18, 2019, at 2:42 PM, David Blaikie via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br><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" target="_blank">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><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<span> </span><i>else’s</i><span> </span>product, it<span> </span><i>would</i><span> </span>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></div></div></div></div></blockquote><div><br></div><div>I’d rephrase this: it’s not currently something that LLVM developers have tried to address, and it’s known to be insecure. Were someone to come in and commit significant amount of work, it would definitely be something we can support.</div><div><br></div><div>I don’t want to say “non-goal” without explaining *why* that’s the case, and what can be done to change things. In other words, if the security group is willing to call something security-related, then it is. Whoever is in that group has to put in the effort to address an issue. Until such people are part of the group, the group should respond to issues of this kind as “out of scope because <good reason>”.</div><div><br></div><div>I agree we should document those reasons as we encounter them! I just don’t think we should try to enumerate them right now. We’ll have a transparency report, and that’s a great opportunity to revisit what we think is / isn’t in scope, and call it out.</div></div></div></blockquote><div><br></div>I think that's a problematic way to go about things, because the security group has limited membership and the discussions are private and limited -- even if there's limited visibility after-the-fact. That is certainly a necessary and desirable property when working to resolve undisclosed vulnerabilities, but it is not when making general decisions about what we as a project want to claim to support. Of course, we all will need to trust the people on the security group to make certain decisions on a case-by-case basis, but the discussion about what we want to be security supported should be -- must be -- public.</div><div class="gmail_quote"><br></div><div class="gmail_quote">This is not simply about deciding how to resolve an <i>issue</i> that's reported externally, it's about the entire process. The project needs to be on the same page as to what our security boundaries are, otherwise the security group will just end up just doing CVE-issue-response theater.</div><div><br></div><div class="gmail_quote"><div>And I do agree that if someone were to come in and put in the significant amounts of work to make LLVM directly usable in security-sensitive places, then we could support that. But none of that should have anything to do with the security group or its membership. All of that work and discussion, and the decision to support it in the end, should be done as a project-wide discussion and decision, just like anything else that's worked on.</div><div><br></div><div><br></div><div></div></div></div>