Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 17 Sep 2017 09:59:11 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security <oss-security@...ts.openwall.com>
Cc: Alexander Batischev <eual.jp@...il.com>
Subject: Re: Podbeuter podcast fetcher: remote code execution

On Sun, Sep 17, 2017 at 9:21 AM, Solar Designer <solar@...nwall.com> wrote:

> 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.
>

While this should not be the case, it often is. And TBH this is one of the
reasons I'm trying to make CVE easier.


> 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.
>

This is also not true, many orgs (probably not open source distros run by
volunteers, but more big corps) literally do have a clock start ticking
when a CVE comes to light, I know for Red Hat it doesn't matter if the
issue has a CVE or not (we obviously prefer to have one as it makes talking
about it and coordinating a response easier), but I can't speak for others
obviously.


>
> > 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.
>

Yup.


>
> > 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
>



-- 

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@...hat.com

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ