[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
