[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<DB9P189MB204951E97ACF9DB11D029E50C3382@DB9P189MB2049.EURP189.PROD.OUTLOOK.COM>
Date: Sun, 31 Mar 2024 02:57:21 +0000
From: Markus Klyver <markusklyver@...mail.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: SV: Re: backdoor in upstream xz/liblzma leading to ssh
server compromise
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@...il.com>
Skickat: den 31 mars 2024 01:35
Till: oss-security@...ts.openwall.com <oss-security@...ts.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@...i.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).
>
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.
