Re: Podbeuter podcast fetcher: remote code execution

[Kurt Seifried <kseifried () redhat com>]

On Sun, Sep 17, 2017 at 9:21 AM, Solar Designer <solar () openwall 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 () redhat com