Date: Sat, 8 Aug 2020 15:21:35 +0200 From: Solar Designer <solar@...nwall.com> To: Daniel Ruggeri <druggeri@...che.org> Cc: oss-security@...ts.openwall.com, HTTPD Security <security@...pd.apache.org> Subject: Re: CVE-2020-11984: Apache httpd: mod_uwsgi buffer overlow On Sat, Aug 08, 2020 at 07:02:21AM -0500, Daniel Ruggeri wrote: > As you can > imagine, with such a strong downstream community from our releases, we > try to be careful so as to not place too much information in the > descriptions to make it trivial to exploit vulnerabilities before those > downstream packagers can incorporate fixes. No, I couldn't have imagined that a well-established Open Source project like Apache httpd would still use this flawed practice of 20+ years ago. The current practice is to include all information that is helpful to address the issue, including by downstream packagers, who in many cases will need to do backports rather than merely update to a new release. By deliberately withholding information as a standard practice, you hurt not only those who would exploit the vulnerabilities, but also (and even more certainly) those who would fix them. It'd have to be some rare special case with specific reasoning to decide on temporarily withholding anything from an otherwise public disclosure, and then you'd need to have a specific plan on disclosing the rest on a specific date (ideally pre-announced). For example, this can be done to separate the disclosure of full vulnerability and fix detail (sufficient for backports) vs. publication of an exploit by a week, like e.g. Qualys has done on some recent occasions where exploitation was not trivial. If you're not planning on publishing exploitation techniques, there's usually nothing you can reasonably withhold from the initial disclosure. If you do want to reduce the window of exposure, there are ways to give your downstream packagers a few days (and ideally no more than that) to incorporate the fixes privately before you disclose the issues publicly. We host the distros list for this, and you may also contact some of your other downstreams separately. I am not saying you should be doing that, but rather I am saying that if you're not doing it (which is fine), then you shouldn't try to make your public disclosures cryptic as a way to compensate for that. I think it doesn't have a net positive effect. So my suggestion is that for most issues you just disclose everything publicly right away, and for occasional highest-severity issues you notify some of your downstreams in private first (unfortunately, no way to notify all without making the issue public) and give them just a little time before you disclose everything publicly. 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.