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

[Markus Klyver <markusklyver () hotmail com>]

In particular, people shouldn't be able to push blobs to projects without some form of checking of the blobs.
________________________________
Från: Pat Gunn <pgunn01 () gmail com>
Skickat: den 31 mars 2024 01:35
Till: oss-security () lists openwall com <oss-security () lists openwall com>
Ämne: Re: [oss-security] Re: backdoor in upstream xz/liblzma leading to ssh server compromise

I hope this spurs efforts to create better tools and follow software
practices that might make it easier to spot this kind of thing. I wouldn't
be surprised if there are other commonly-used tools that already are
compromised but don't have performance issues that have yet led someone
down the "that's funny" path that leads to easy discovery.

On Sat, 30 Mar 2024 at 20:25, Jan Engelhardt <jengelh () inai de> wrote:

> On Saturday 2024-03-30 21:43, Mats Wichmann wrote:
> > On 3/30/24 09:32, Jeffrey Walton wrote:
> >
> > > > Someone asked what would become of xz as a project. I do hope in
> > > > light of this event, some people step in to help.
> > >
> > > Perhaps Lasse should turn over control of the project to an entity
> >
> > In light of this scenario (at least what I understand about it),
> > it's got to be even harder now for an overloaded maintainer to
> > accept help of a significant nature.
>
> I think it may not make much of a difference.
>
>
> In the instance of xz, the usurper convinced maintainers with
> contributions over the course of some 2 years to gain reasonable
> control of the project, and in essence, users.
>
> If instead, we picture that a maintainer withholds control (either due
> to lack of will, or lack of time), an usurper would have to start a fork
> and convince *users* directly to trust and favor the replacement, an
> undertaking which might have reasonably taken about 2-3 years as well
> (judging from the timeframes it took libjpeg-turbo or systemd to get a
> footing in distros).
>
>
> Other software might have completely different "usurp time"
> characteristics. That all depends on both how integrated a software
> is in the larger ecosystem and how many users there already are that
> would care (for either an improvement or when it breaks).