<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On 15 Nov 2019, at 19:58, JF Bastien via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><font face="HelveticaNeue" class=""><span style="caret-color: rgb(0, 0, 0);" class="">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 style="caret-color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">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" class="">available on Phabricator</a><font face="HelveticaNeue" class=""><span style="caret-color: rgb(0, 0, 0);" class="">. The proposal starts with a list of goals for the process and Security Group, repeated here:</span><br style="caret-color: rgb(0, 0, 0);" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">The LLVM Security Group has the following goals:</span><br style="caret-color: rgb(0, 0, 0);" class=""></font><ol style="caret-color: rgb(0, 0, 0);" class=""><li class=""><font face="HelveticaNeue" class="">Allow LLVM contributors and security researchers to disclose security-related issues affecting the LLVM project to members of the LLVM community.</font></li><li class=""><font face="HelveticaNeue" class="">Organize fixes, code reviews, and release management for said issues.</font></li><li class=""><font face="HelveticaNeue" class="">Allow distributors time to investigate and deploy fixes before wide dissemination of vulnerabilities or mitigation shortcomings.</font></li><li class=""><font face="HelveticaNeue" class="">Ensure timely notification and release to vendors who package and distribute LLVM-based toolchains and projects.</font></li><li class=""><font face="HelveticaNeue" class="">Ensure timely notification to users of LLVM-based toolchains whose compiled code is security-sensitive, through <a href="https://cve.mitre.org/" class="">the CVE process</a>.</font></li></ol><font face="HelveticaNeue" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">We’re looking for answers to the following questions:</span><br style="caret-color: rgb(0, 0, 0);" class=""></font><ol style="caret-color: rgb(0, 0, 0);" class=""><li class=""><font face="HelveticaNeue" class=""><u class="">On this list</u>: Should we create a security group and process?</font></li></ol></div></div></blockquote><div>Yes, I think that is a good idea.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="2"><li class=""><font face="HelveticaNeue" class=""><u class="">On this list</u>: Do you agree with the goals listed in the proposal?</font></li></ol></div></div></blockquote><div>Yes, but I hope we can clarify what "time to investigate" and "timely notification" means, in more precise terms.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="3"><li class=""><font face="HelveticaNeue" class=""><u class="">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></ol></div></div></blockquote><div>With regards to the embargo time limits, I think that 90 days is a rather long minimum time. Remember that major LLVM release cycles are just ~180 days! Then again, I realize that some downstream organizations have very elaborate release cycle procedures. I just wish they were shorter for critical security issues.</div><div><br class=""></div><div>I also think that fourteen weeks from a commit landing to making the issue public is not really doable. Are we really going to commit something with a message "what this commit does is a secret, see you in 14 weeks" ? And then expect nobody to just look at what the changes entail, and derive the actual issue from that? It seems unrealistic, to say the least.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="4"><li class=""><font face="HelveticaNeue" class=""><u class="">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></ol></div></div></blockquote><div>I'll post the above on the review</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="5"><li class=""><font face="HelveticaNeue" class=""><u class="">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 class=""><li class=""><font face="HelveticaNeue" class="">Are you an LLVM contributor (individual or representing a company)?</font></li></ol></ol></div></div></blockquote><div>I am both an individual contributor to LLVM, and a member of the FreeBSD community, where I am mostly responsible for maintaining the LLVM fork (well, just plain LLVM with a few hacks and additional patches) in the FreeBSD source tree.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="5"><ol class="" start="2"><li class=""><font face="HelveticaNeue" class="">Are you involved with security aspects of LLVM (if so, which)?</font></li></ol></ol></div></div></blockquote><div>Not especially, though I have been involved with diagnosing quite a number of LLVM crash bugs, of which at least some could possibly be abused in security contexts. That said, I have not been actively searching for any security holes.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="5"><ol class="" start="3"><li class=""><font face="HelveticaNeue" class="">Do you maintain significant downstream LLVM changes?</font></li></ol></ol></div></div></blockquote><div>No, we try to keep the differences between stock LLVM components and the FreeBSD versions as small as possible. We do, however apply a few minor customizations, and quite a number of post-release patches. Most of these are to fix issues with compiling the rather large FreeBSD ports collection (roughly 33,000 of them), for a number of different architectures.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="5"><ol class="" start="4"><li class=""><font face="HelveticaNeue" class="">Do you package and deploy LLVM for others to use (if so, to how many people)?</font></li></ol></ol></div></div></blockquote><div>Yes, we build LLVM components such as clang, compiler-rt, libc++, lld, lldb and a number of llvm tools as part of the FreeBSD base system. These are shipped as releases in binary and source code form. Regular snapshots (roughly every week) are also made available.</div><div><br class=""></div><div>FreeBSD is used by quite a number of people and organizations, but since the project does not actively track its users, I don't know any hard (or even semi-soft :) numbers. There are also a number of projects downstream from FreeBSD, such as FreeNAS and TrueOS.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="5"><ol class="" start="5"><li class=""><font face="HelveticaNeue" class="">Is your LLVM distribution based on the open-source releases?</font></li></ol></ol></div></div></blockquote><div>Yes, and almost all the patches we apply are from the regular LLVM trunk or master.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="5"><ol class="" start="6"><li class=""><font face="HelveticaNeue" class="">How often do you usually deploy LLVM?</font></li></ol></ol></div></div></blockquote><div>Normally we update to each new major and minor release as they appear, and we are also involved in the testing process before those releases. Since not every bug that affects FreeBSD can get fixed, we also regularly apply fixes post LLVM releases.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="5"><ol class="" start="7"><li class=""><font face="HelveticaNeue" class="">How fast can you deploy an update?</font></li></ol></ol></div></div></blockquote><div>If any issue affects a released version of FreeBSD, it will be handled by the FreeBSD Security Team. They will investigate the severity of the issue and the impact, verify if the fix(es) apply and have the promised mitigating effect, and obviously determine if there are no negative side effects. Then they will build new binary bits that go out via the binary update system we use, a.k.a freebsd-update. Building the bits can be done in a few days, but the investigation is harder to pin down time-wise.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="5"><ol class="" start="8"><li class=""><font face="HelveticaNeue" class="">Does your LLVM distribution handle untrusted inputs, and what kind?</font></li></ol></ol></div></div></blockquote><div>The toolchain parts, e.g. clang, lld and lldb, can obviously be used for arbitrary source code, but will seldom be useful for e.g. privilege escalations. Other parts, such as compiler-rt and libc++, are installed as system wide dynamic libraries. Vulnerabilities in these could affect any application on the system which links to them.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><ol style="caret-color: rgb(0, 0, 0);" class="" start="5"><ol class="" start="9"><li class=""><font face="HelveticaNeue" class="">What’s the threat model for your LLVM distribution?</font></li></ol></ol></div></div></blockquote><div>As described in the previous item, specifically the compiler-rt and libc++ libraries can be dependencies of many applications, some of which will be part of the system, and also be security sensitive. (For example, FreeBSD's device daemon devd <<a href="https://www.freebsd.org/cgi/man.cgi?query=devd" class="">https://www.freebsd.org/cgi/man.cgi?query=devd</a>> is written in C++, and linked to libc++.)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><font face="HelveticaNeue" class=""><br style="caret-color: rgb(0, 0, 0);" class=""><span style="caret-color: rgb(0, 0, 0);" class="">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 style="caret-color: rgb(0, 0, 0);" class=""></font><ul style="caret-color: rgb(0, 0, 0);" class=""><li class=""><a href="https://webkit.org/security-policy/" class=""><font face="HelveticaNeue" class="">https://webkit.org/security-policy/</font></a></li><li class=""><a href="https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md" class=""><font face="HelveticaNeue" class="">https://chromium.googlesource.com/chromium/src/+/lkgr/docs/security/faq.md</font></a></li><li class=""><a href="https://wiki.mozilla.org/Security" class=""><font face="HelveticaNeue" class="">https://wiki.mozilla.org/Security</font></a></li><li class=""><a href="https://www.openbsd.org/security.html" class=""><font face="HelveticaNeue" class="">https://www.openbsd.org/security.html</font></a></li><li class=""><a href="https://security-team.debian.org/security_tracker.html" class=""><font face="HelveticaNeue" class="">https://security-team.debian.org/security_tracker.html</font></a></li><li class=""><a href="https://www.python.org/news/security/" class=""><font face="HelveticaNeue" class="">https://www.python.org/news/security/</font></a></li></ul><font face="HelveticaNeue" class=""><span style="caret-color: rgb(0, 0, 0);" class="">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 style="caret-color: rgb(0, 0, 0);" class=""></font></div></div></blockquote><div><br class=""></div><div>I haven't interacted with any of the above security groups. But I have interacted with the FreeBSD Security Team, which has a page here <<a href="https://www.freebsd.org/security/" class="">https://www.freebsd.org/security/</a>>. Their process is fairly straightforward, and most of it is handled via email and a private Bugzilla instance.</div><div><br class=""></div></div><div class="">-Dimitry</div><div class=""><br class=""></div></body></html>