Date: Sun, 17 Sep 2017 17:21:43 +0200 From: Solar Designer <solar@...nwall.com> To: Alexander Batischev <eual.jp@...il.com> Cc: oss-security@...ts.openwall.com Subject: Re: Podbeuter podcast fetcher: remote code execution On Sun, Sep 17, 2017 at 02:55:12PM +0300, Alexander Batischev wrote: > On Sat, Sep 16, 2017 at 09:05:44PM +0200, Solar Designer wrote: > >"Instead, please start by posting about the (to be made) public issue > >to oss-security (without a CVE ID), request a CVE ID from MITRE > >directly, and finally "reply" to your own posting when you also have > >the CVE ID to add." > > I was under impression that having a CVE ID speeds up processes in > distros, and fixes are released quicker. This might be the case for some issues and some distros, such as when having a CVE ID is deemed to indicate the issue is serious or has to be patched for publicity reasons. It may be that it's easier to ignore an issue that doesn't yet have a CVE ID, publicity-wise. While CVE IDs are helpful for tracking, they should not be required, so if a distro technically can't promptly process issues without CVE IDs (I am unaware of such cases), they need to revise their processes anyhow. > Was my impression wrong? I'm unaware of statistics to confirm or disprove your impression. If someone has such data and analysis, please share. Intuitively, I'd expect having or lacking a CVE ID to affect priority more than it affects capability to track. Ideally it shouldn't affect either, but realistically I expect that it sometimes does. > I just want to do things "right", so that > attackers have as little time as possible to exploit users. (I do > realize this all is best-effort and distros might still take time to > release, and then users might take ages to upgrade.) You're talking about the window of exposure: time period since public disclosure of an issue and until it gets patched. However, this metric varies across users and distros, and it's not the only metric. It's also desirable to get the issue known and fixed sooner. Now, an extra three weeks (as in your most recent case) isn't unacceptably bad as long as the chances of abuse or leaks during this period are low, but you do slightly increase this risk by reporting to MITRE. Although I'm unaware of evidence there's ever been abuse by or leaks from MITRE, and there have been fairly convincing statements to the contrary, I think it's good practice to avoid or at least minimize the pre-public-disclosure exposure to MITRE as it serves no other purpose than getting CVE IDs assigned, which in my opinion does not justify even minor risk. > Now that I had an experience of waiting for three weeks, I'll also > re-consider if I want to become a CNA for my project. Previously it > seemed like a hassle; I'm not so sure now. This does seem like a hassle to me. Probably not worth it. Publicly disclosing without CVE IDs and adding them later is probably better. You can always use your own tracking IDs to add clarify (so that e.g. different issues are not erroneously lumped together), or use OVE IDs: http://www.openwall.com/ove/ then associate them with CVE IDs when you have those, such as in a revision of your advisory. See e.g. how Xen publishes revised versions of their advisories when they add CVE IDs. 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.