Date: Sat, 26 Aug 2023 00:23:59 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Cc: Vegard Nossum <vegard.nossum@...cle.com>, Jiri Kosina <jkosina@...e.cz>, Donald Buczek <buczek@...gen.mpg.de>, Greg KH <gregkh@...uxfoundation.org> Subject: linux-distros list policy and Linux kernel, again Hi, This is sort of continuation to a thread I started in here last year, at the time focusing on allowing "embargoes" on publicly fixed Linux kernel issues, which we ended up agreeing to: https://www.openwall.com/lists/oss-security/2022/05/15/1 BTW, this recent thread on "Quality standards for embargoed code" is relevant to that previous topic: https://lore.kernel.org/ksummit/2023081527-amendment-professed-0a42@gregkh/T/#t (It's harder/worse to test code changes that are not yet public, which is something we also recently discussed in context of and granted an exception to the curl project.) This time, there are at least two more points of contention to discuss. Thank you Donald Buczek for bringing this to oss-security (and beating me to it), with your specific needs explained: https://www.openwall.com/lists/oss-security/2023/08/25/1 https://lore.kernel.org/ksummit/nycvar.YFH.email@example.com/T/#t Here I'd like to start a new thread just on oss-security (no cross-post, but some people CC'ed) and with more context given. For some years until recently, the Linux kernel's Documentation/admin-guide/security-bugs.rst directed people to also report "sensitive bugs, such as those that might lead to privilege escalations" to linux-distros. On one hand, that was great - cooperation between Linux kernel upstream and Linux distros. On the other hand, the specific wording did not fully match linux-distros policy, yet it bypassed a visit to the wiki page on linux-distros with the instructions and policy on it by directly giving out the posting address. This resulted in people reporting issues to linux-distros without having actually read and accepted the policy. Last year, Vegard Nossum suggested edits (and then revised them this year) to try and make things much clearer for reporters: https://firstname.lastname@example.org/ https://vegard.github.io/security-v3/Documentation/output/process/security-bugs.html As I recall, when Vegard offered this edited documentation (the second URL above) to people who reported something to linux-distros but were confused, they said that version of the documentation was indeed much clearer. However, the changes didn't get merged, which I speculate is in part a result of them changing several things at once and thus making it harder for all reviewers to agree on them. Besides, I am not sure this was the right direction: maybe rather than duplicate and explain linux-distros policy aspects in Linux kernel documentation, it was better to refer to linux-distros instructions and omit the linux-distros posting address from the kernel documentation. Then there was the recent lengthy linux-distros and email@example.com thread on the StackRot (CVE-2023-3269) vulnerability, publicly disclosed here: https://www.openwall.com/lists/oss-security/2023/07/05/1 In that private thread, two linux-distros policy aspects came up as being inconsistent with firstname.lastname@example.org preferences: 1. For email@example.com, public disclosure is typically in up to 7 days since fix is ready, but for linux-distros the deadline is 14 days max since linux-distros is notified even if the fix is not ready. Apparently, this one makes Greg KH particularly unhappy about linux-distros. 2. _If_ the reporter shares PoCs/exploits with linux-distros, then per current policy those should also be made public (within up to 7 days more after the vulnerability is publicly disclosed as such). Linus Torvalds said that this must be up to the reporter only, and we should not be imposing such policy. In a sense, this is already up to the reporter - if they disagree, they just shouldn't post PoCs/exploits to linux-distros - can instead post an offer to share with individual distros if they want to, or not share at all. However, this is problematic in practice because not everyone reads the rules before posting and sometimes people change their mind during the embargo time (or are required to "change their mind" by their employer, etc.) I had already recognized both of these as problems - e.g., the latter one also came up in Mathias Krause's disclosure of another Linux kernel vulnerability in 2022: https://www.openwall.com/lists/oss-security/2022/02/03/1 At the time, I thought that maybe increasing the maximum delay for PoC/exploit publication from 7 to 30 days would be appropriate, but we did not formally do it. I effectively granted a similar exception to Ruihan Li for StackRot this time, even though the full exploit wasn't even shared with linux-distros and Ruihan was willing to publish the PoCs that he did share on time. I also informed Ruihan of this policy aspect early enough, so we dodged that bullet that time, but at the same time made Linus aware of this general issue, triggering his criticism. (That's fine, it's good to have criticism.) Overall, even though these issues were mostly avoided for StackRot in particular, bringing them up in this thread ended up being the last straw for the Linux kernel security folks to say they don't want to deal with linux-distros anymore, resulting in this edit to the documentation: https://git.kernel.org/linus/4fee0915e649b This has a spiteful commit message and a calmer almost constructive actual change. Knowing that the status quo was problematic and not having a better solution ready (other than Vegard's elaborate edits), I actually approved of this edit as well. It says: --- The kernel security team strongly recommends that reporters of potential security issues NEVER contact the "linux-distros" mailing list until AFTER discussing it with the kernel security team. Do not Cc: both lists at once. You may contact the linux-distros mailing list after a fix has been agreed on and you fully understand the requirements that doing so will impose on you and the kernel community. The different lists have different goals and the linux-distros rules do not contribute to actually fixing any potential security problems. --- (I take issue with the second paragraph, as I explained in the message Donald forwarded in here earlier today.) So the kernel security team can, after having arrived at a fix, choose to direct the reporter to also contact linux-distros. I don't know whether this would actually be happening or not. Maybe some friendly dialogue (which I hope this message can be a part of) and agreeing on things could make that more likely. I think the two linux-distros policy aspects above do not preclude such cooperation. However, I am willing to discuss possible policy changes (or perhaps Linux kernel exceptions). I recognize that 14 days might not always be enough to get a fix ready, especially not for many of the CPU microarchitectural issues being handled since mid-2017 and affecting many proprietary OSes as well (who may be used to much longer disclosure timelines and would object to Linux's earlier fix and disclosure). I am glad that almost none of such issues were brought to (linux-)distros, and never when it was still more than 14 days until public disclosure. We had a lot of luck there. Linux kernel security team has its own mailing list (encrypted, so more secure than firstname.lastname@example.org) for handling of those, which is great: https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html I mean, this is "great" within the constraints of the rest of the industry. Of course, I'd very much like disclosure timelines for that kind of issues to also become much shorter. This is just not the case. In terms of (linux-)distros list policy, what can we do here? Accept up to 7 days since fix is ready and thus accept arbitrarily long embargoes and more likely have issues "requiring" such embargoes brought to the list? BTW, for CPU microarchitectural issues, that would probably need to be for the full distros list, not limited to Linux, and from what I know disclosure timelines for such issues may be 3 to 12+ months. As to publishing PoCs/exploits, this is already mitigated by the Linux kernel documentation edit making it less likely (but far from impossible) that people would send stuff to linux-distros without being aware of the policy. We could further mitigate this issue by allowing up to 30 days (but perhaps suggesting at most 7 days?) As I recall, how much time to allow here was first discussed in context of an Exim issue that was expected to be so easy to independently come up with an exploit for that even 7 days seemed excessive, so 24 hours was agreed upon for that occasion: https://www.openwall.com/lists/oss-security/2019/06/05/4 However, issues vary, and maybe 1 to 30 days on a case-by-case basis is reasonable? Another option is to completely remove this requirement (only for Linux kernel issues or for all), but there are reasons to keep it: 1. To reduce the value of information staying in linux-distros members' mailboxes/computers to potential attackers. The issues with highly valuable information staying in there are that such people/resources become more lucrative attack targets, and that compromises/leaks might not be detected, in which case the situation is worse than with full publication (only bad actors benefit). 2. To let the wider community benefit from those PoCs/exploits. There are many uses for PoCs/exploits other than testing by upstream developers or attacking systems in the wild. Other uses include: testing of (possibly different or backported) fixes by other distros (not all of which are on linux-distros for a variety of reasons) and by advanced users, reuses by other developers and security researchers to better understand the problem and as templates for further PoC/exploit development (such as in determining and demonstrating exploitability of further related bugs), testing and improvement of (non-)effectiveness of general security hardening mitigations and of security monitoring tools. I'd appreciate any well-reasoned votes and constructive suggestions. Maybe there are good ideas that didn't cross my mind yet. Thanks, Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.