Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise

[Marc Deslauriers <marc.deslauriers () canonical com>]

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.