[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 30 Mar 2024 07:50:56 +0400
From: Loganaden Velvindron <loganaden@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Re: backdoor in upstream xz/liblzma leading to ssh
server compromise
Github has suspended the repo:
https://github.com/tukaani-project/xz
Im wondering what is the next step for the xz project as a whole ?
On Sat, Mar 30, 2024, 03:58 Tavis Ormandy <taviso@...il.com> wrote:
> On 2024-03-29, Marc Deslauriers wrote:
> >> 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.
> >
>
> Yeah... but you also have no reason to not believe that?
>
> What do you propose they were doing with their backdoor?
>
> > 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.
> >
>
> Okay, but do we agree that if there is a mitigation available, it's better
> for it to be public?
>
> Isn't doing `dnf downgrade xxx` a mitigation, or `systemctl xxx stop`?
>
> >>
> >> 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 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.
>
> We all want users to be secure as fast as possible. The discussion is
> whether keeping backdoors embargoed helps achieve that.
>
> Tavis.
>
> --
> _o) $ lynx lock.cmpxchg8b.com
> /\\ _o) _o) $ finger taviso@....org
> _\_V _( ) _( ) @taviso
>
>
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.
