[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6038e843-fc3f-4c51-a48c-feb283242b41@canonical.com>
Date: Fri, 29 Mar 2024 19:15:11 -0400
From: Marc Deslauriers <marc.deslauriers@...onical.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: backdoor in upstream xz/liblzma leading to ssh
server compromise
On 2024-03-29 18:59, Liguori, Anthony wrote:
> On 2024-03-29, Andres Freund wrote:
>> Hi,
>>
>> On 2024-03-29 21:54:11 -0000, Tavis Ormandy wrote:
>>> On 2024-03-29, Solar Designer wrote:
>>>>> I have a minor procedural question for Solar though, shouldn't this
>>>>> have been redirected to oss-security immediately from distros? What's
>>>>> the rationale for an embargo here?
>>>>
>>>> We don't have a clear policy for such case. Some distros list members
>>>> have indeed suggested making this public ASAP. We ended up delaying
>>>> publication by one day per my suggestion (as a compromise between ASAP
>>>> and having no specific CRD), and I think these are some reasons why:
>>>
>>> Thanks, a compromise is better than nothing :) I think I would have
>>> argued for immediately discussing this in the open.
>>
>> FWIW, I don't know much of the tradeoffs in this space. With that caveat:
>
> I think we should have a policy that if issues are suspected to be actively exploited, that the issue goes public immediately. If even there is no patch or mitigation, there's not a lot of benefit to keeping it private.
In this case, we had no reason to believe it was being actively exploited.
If you make it public before a patch or mitigation is available, it has now gone
from a single entity being able to exploit it to the whole world being able to
exploit it.
That's a whole lot worse.
>
> I think everyone was acting in good faith here and did great work, but there wasn't a clear policy for handling this type of issue.
>
> I very much agree that there's very little benefit to limiting the number of folks that know what's going on when someone is actively taking advantage of an issue.
>
I would argue against having a policy requiring something like this to be made
public immediately. The important thing here is to do whatever it takes to make
sure users are secure as fast as possible, not expose them to even bigger attack
surface with no mitigation available.
Marc.
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.
