<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 4, 2019 at 3:36 PM JF Bastien <<a href="mailto:jfbastien@apple.com">jfbastien@apple.com</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 style="overflow-wrap: break-word;"><br><div><blockquote type="cite"><div>On Nov 26, 2019, at 6:31 PM, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:</div><br><div><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On this list: Should we create a security group and process?<br></blockquote><div><br></div><div>Yes, as long as it is a funded mandate by several major contributors. </div><div>We can't run it as a volunteer group. </div></div></div></blockquote><div><br></div><div>I expect that major corporate contributors will want some of their employees involved. Is that the kind of funding you’re looking for? </div></div></div></blockquote><div><br></div><div>Yes! </div><div> </div><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;"><div><div>Or something additional?</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div>Also, someone (this group, or another) should do proactive work on hardening the </div>sensitive parts of LLVM, otherwise it will be a whack-a-mole. <div>Of course, will need to decide what are those sensitive parts first. <br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On this list: Do you agree with the goals listed in the proposal?<br></blockquote><div><br></div><div>In general - yes. </div><div>Although some details worry me. </div><div>E.g. I would try to be stricter with disclosure dates. </div>> public within approximately fourteen weeks of the fix landing in the LLVM repository<div>is too slow imho. it hurts the attackers less than it hurts the project. </div><div>oss-fuzz will adhere to the 90/30 policy</div></div></div></div></blockquote><div><br></div><div>This specific bullet followed the Chromium policy:</div><div><a href="https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md#Can-you-please-un_hide-old-security-bugs" target="_blank">https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md#Can-you-please-un_hide-old-security-bugs</a></div><div><br></div><div>Quoting it:</div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><div>Our goal is to open security bugs to the public once the bug is fixed and the fix has been shipped to a majority of users. However, many vulnerabilities affect products besides Chromium, and we don’t want to put users of those products unnecessarily at risk by opening the bug before fixes for the other affected products have shipped.</div></div><div><div><br></div></div><div><div>Therefore, we make all security bugs public within approximately 14 weeks of the fix landing in the Chromium repository. The exception to this is in the event of the bug reporter or some other responsible party explicitly requesting anonymity or protection against disclosing other particularly sensitive data included in the vulnerability report (e.g. username and password pairs).</div></div></blockquote><div><div><br></div><div>I think the same rationale applies to LLVM.</div></div></div></blockquote><div><br></div><div>ACK. If the OSS-Fuzz 90/30 policy doesn't work for LLVM, </div><div>we could spin an independent instance of ClusterFuzz.</div><div>(Of course, at some extra maintenance and VM cost)</div><div>Although I would rather not do that if we can avoid it. </div><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;"><div><div><br></div><div><br></div><blockquote type="cite"><div dir="ltr"><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On this list: at a high-level, what do you think should be done differently, and what do you think is exactly right in the draft proposal?<br></blockquote><div><br></div><div></div><div>The process seems to be too complicated, but no strong opinion here. </div><div>Do we have another example from a project of similar scale? </div></div></div></div></blockquote><div><br></div><div>Yes, the email lists some. WebKit’s process resembles the one I propose, but I’ve expanded some of the points which it left unsaid. i.e. in many cases it has the same content, but not as spelled out.</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On the Phabricator code review: going into specific details, what do you think should be done differently, and what do you think is exactly right in the draft proposal?<br></blockquote><div><br></div><div>commented on GitHub vs crbug<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On this list: to help understand where you’re coming from with your feedback, it would be helpful to state how you personally approach this issue:<br>Are you an LLVM contributor (individual or representing a company)?<br></blockquote><div>Yes, representing Google. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Are you involved with security aspects of LLVM (if so, which)?<br></blockquote><div><br></div><div>To some extent:</div><div>* my team owns tools that tend to find security bugs (sanitizers, libFuzzer)</div><div>* my team co-owns oss-fuzz, which automatically sends security bugs to LLVM </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Do you maintain significant downstream LLVM changes?<br></blockquote><div><br></div><div>no</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Do you package and deploy LLVM for others to use (if so, to how many people)?<br></blockquote><div><br></div><div>not my team</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is your LLVM distribution based on the open-source releases?<br></blockquote><div><br></div><div>no</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">How often do you usually deploy LLVM?<br></blockquote><div><br></div><div>In some ecosystems LLVM is deployed ~ every two-three weeks. </div><div>In others it takes months. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">How fast can you deploy an update?<br></blockquote><div><br></div><div>For some ecosystems we can turn around in several days. </div><div>For others I don't know. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Does your LLVM distribution handle untrusted inputs, and what kind?<br></blockquote><div><br></div><div>Third party OSS code that is often pulled automatically. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">What’s the threat model for your LLVM distribution?</blockquote><div><br></div><div>Speculating here. I am not a real security expert myself</div><div>* A developer getting a bug report and running clang/llvm on the "buggy" input, compromising the developer's desktop. </div><div>* A major opensource project is compromised and it's code is changed in a subtle way that triggers a vulnerability in Clang/LLVM.</div><div> The opensource code is pulled into an internal repo and is compiled by clang, compromising a machine on the build farm. </div><div>* A vulnerability in a run-time library, e.g. <a href="http://crbug.com/606626" target="_blank">crbug.com/606626</a> or <a href="http://crbug.com/994957" target="_blank">crbug.com/994957</a></div><div>* (???) Vulnerability in a LLVM-based JIT triggered by untrusted bitcode. <2-nd hand knowledge></div><div>* (???) an optimizer introducing a vulnerability into otherwise memory-safe code (we've seen a couple of such in load & store widening)</div><div>* (???) deficiency in a hardening pass (CFI, stack protector, shadow call stack) making the hardening inefficient. </div><div><br></div><div>My 2c on the policies: if we actually treat some area of LLVM security-critical, <br></div><div>we must not only ensure that a reported bug is fixed, but also that the affected component gets</div><div>additional testing, fuzzing, and hardening afterwards. </div><div>E.g. for <a href="http://crbug.com/994957" target="_blank">crbug.com/994957</a> I'd really like to see a fuzz target as a form of regression testing.</div></div></div></div></blockquote><div><br></div><div>Thanks, this is great stuff!</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><div><div>--kcc <br></div><div> </div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 16, 2019 at 8:23 AM JF Bastien 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><h1><span style="font-weight:normal;font-size:12px"><font face="HelveticaNeue">Hello compiler enthusiasts,</font></span></h1><font face="HelveticaNeue"><span><div><font face="HelveticaNeue"><span><br></span></font></div>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.</span><br><br><span>A draft proposal for how we could organize such a group and what its process could be is </span></font><a href="https://reviews.llvm.org/D70326" target="_blank">available on Phabricator</a><font face="HelveticaNeue"><span>. The proposal starts with a list of goals for the process and Security Group, repeated here:</span><br><br><span>The LLVM Security Group has the following goals:</span><br></font><ol><li><font face="HelveticaNeue">Allow LLVM contributors and security researchers to disclose security-related issues affecting the LLVM project to members of the LLVM community.</font></li><li><font face="HelveticaNeue">Organize fixes, code reviews, and release management for said issues.</font></li><li><font face="HelveticaNeue">Allow distributors time to investigate and deploy fixes before wide dissemination of vulnerabilities or mitigation shortcomings.</font></li><li><font face="HelveticaNeue">Ensure timely notification and release to vendors who package and distribute LLVM-based toolchains and projects.</font></li><li><font face="HelveticaNeue">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>.</font></li></ol><font face="HelveticaNeue"><br><span>We’re looking for answers to the following questions:</span><br></font><ol><li><font face="HelveticaNeue"><u>On this list</u>: Should we create a security group and process?</font></li><li><font face="HelveticaNeue"><u>On this list</u>: Do you agree with the goals listed in the proposal?</font></li><li><font face="HelveticaNeue"><u>On this list</u>: at a high-level, what do you think should be done differently, and what do you think is exactly right in the draft proposal?</font></li><li><font face="HelveticaNeue"><u>On the Phabricator code review</u>: going into specific details, what do you think should be done differently, and what do you think is exactly right in the draft proposal?</font></li><li><font face="HelveticaNeue"><u>On this list</u>: to help understand where you’re coming from with your feedback, it would be helpful to state how you personally approach this issue:</font></li><ol><li><font face="HelveticaNeue">Are you an LLVM contributor (individual or representing a company)?</font></li><li><font face="HelveticaNeue">Are you involved with security aspects of LLVM (if so, which)?</font></li><li><font face="HelveticaNeue">Do you maintain significant downstream LLVM changes?</font></li><li><font face="HelveticaNeue">Do you package and deploy LLVM for others to use (if so, to how many people)?</font></li><li><font face="HelveticaNeue">Is your LLVM distribution based on the open-source releases?</font></li><li><font face="HelveticaNeue">How often do you usually deploy LLVM?</font></li><li><font face="HelveticaNeue">How fast can you deploy an update?</font></li><li><font face="HelveticaNeue">Does your LLVM distribution handle untrusted inputs, and what kind?</font></li><li><font face="HelveticaNeue">What’s the threat model for your LLVM distribution?</font></li></ol></ol><font face="HelveticaNeue"><br><span>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><br></font><ul><li><a href="https://webkit.org/security-policy/" target="_blank"><font face="HelveticaNeue">https://webkit.org/security-policy/</font></a></li><li><a href="https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md" target="_blank"><font face="HelveticaNeue">https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md</font></a></li><li><a href="https://wiki.mozilla.org/Security" target="_blank"><font face="HelveticaNeue">https://wiki.mozilla.org/Security</font></a></li><li><a href="https://www.openbsd.org/security.html" target="_blank"><font face="HelveticaNeue">https://www.openbsd.org/security.html</font></a></li><li><a href="https://security-team.debian.org/security_tracker.html" target="_blank"><font face="HelveticaNeue">https://security-team.debian.org/security_tracker.html</font></a></li><li><a href="https://www.python.org/news/security/" target="_blank"><font face="HelveticaNeue">https://www.python.org/news/security/</font></a></li></ul><font face="HelveticaNeue"><span>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.</span><br><br><br><span>I’ll go first in answering my own questions above:</span><br></font><ol><li><font face="HelveticaNeue">Yes! We should create a security group and process.</font></li><li><font face="HelveticaNeue">We agree with the goals listed.</font></li><li><font face="HelveticaNeue">We think the proposal is exactly right, but would like to hear the community’s opinions.</font></li><li><font face="HelveticaNeue">Here’s how we approach the security of LLVM:</font></li><ol><li><font face="HelveticaNeue">I contribute to LLVM as an Apple employee.</font></li><li><font face="HelveticaNeue">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.</font></li><li><font face="HelveticaNeue">We maintain significant downstream changes.</font></li><li><font face="HelveticaNeue">We package and deploy LLVM, both internally and externally, for a variety of purposes, including the clang, Swift, and mobile GPU shader compilers.</font></li><li><font face="HelveticaNeue">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>.</font></li><li><font face="HelveticaNeue">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.</font></li><li><font face="HelveticaNeue">This depends on which release of LLVM is affected.</font></li><li><font face="HelveticaNeue">Yes, our distribution sometimes handles untrusted input.</font></li><li><font face="HelveticaNeue">The threat model is highly variable depending on the particular language front-ends being considered.</font></li></ol></ol><font face="HelveticaNeue"><span>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.</span><br><br><br><span>Thanks,</span><br><br><span>JF</span></font><br><div><font face="HelveticaNeue"><span><br></span></font></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>
</blockquote></div><br></div></blockquote></div></div>