[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180817125244.illsqe3lckimtnms@suse.de>
Date: Fri, 17 Aug 2018 14:52:44 +0200
From: Marcus Meissner <meissner@...e.de>
To: oss-security@...ts.openwall.com
Subject: Re: Rule for releasing fixes for embargoed bugs
Hi,
On Fri, Aug 17, 2018 at 01:45:16PM +0200, Dominique Martinet wrote:
> Hi,
>
> I tried asking this question in private and was told there is no clear
> rule (and opinions vary) on the subject of releasing fixes for bugs
> still under embargo; and to ask the list, so here we go:
>
> When should vendors publish fixes for bugs that are under embargo ?
>
>
> My opinion is that the point of security embargoes, and linux-distro in
> particular, is to give vendors time to prepare a fix so that fixes can
> be released almost immediately after the issue is made public.
>
> Releasing a fix early pretty much leaks the issue to people monitoring
> distro updates, especially if there is a clear changelog that states
> there have been security fixes with a neat summary and sources are
> available.
>
>
> I'm asking because this happened today and some vendor released a kernel
> with patches for CVE-2018-3690 (yet another speculation/side-channel
> vulnerability), but their fix for it broke another component in the
> kernel (RDMA networking) and people trying to fix that bug are now
> wasting their's and everyone's/my time saying they cannot make the RDMA
> issue public because it has been caused by a security fix still under
> embargo.
> At this point, I'm not sure what this is supposed to protect: I have a
> pretty good idea of what the fixes are about and I'm not a security
> researcher, so if I could figure this much I'm sure smarter people can
> use it, and folks who are waiting for the embargo to end before actually
> posting fixes (including upstream!) are now leaving their users in
> trouble.
>
>
> I don't really care about speculation/side channel attacks frankly but
> there's no reason other bugs won't have the same issue, so I think
> "waiting for the issue to be made public before releasing fixes" should
> be made a rule if at all possible.
There seems to be some miscommunation here, which should be directly
clarified with the security team of the affected distribution(s).
Rule of thumb is: when a vendor publishes updates for an issue, the issue
is public and can be referenced publically. I do not understand why you
would get push back unless there are communication problems.
Also FWIW CVE-2018-3690 is an older reference to "Bounds Check Bypass Store",
which is now tracked as CVE-2018-3693 and is public.
Ciao, Marcus
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.
