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

[Vegard Nossum <vegard.nossum () oracle com>]

On 29/03/2024 20:32, Vegard Nossum wrote:
> On 29/03/2024 19:54, Ivan Delalande wrote:
> > On Fri, Mar 29, 2024 at 08:51:26AM -0700, Andres Freund wrote:
> > > For which the exploit code was then adjusted:
> > > https://github.com/tukaani-project/xz/commit/6e636819e8f070330d835fce46289a3ff72a7b89
> > >
> > > Given the activity over several weeks, the committer is either directly
> > > involved or there was some quite severe compromise of their
> > > system. Unfortunately the latter looks like the less likely 
> > > explanation, given
> > > they communicated on various lists about the "fixes" mentioned above.
> > Knowing this, I hope the recent kernel patch series involving the same
> > person to some degree will get extra scrutiny:
> > https://lore.kernel.org/lkml/20240320183846.19475-1-lasse.collin () tukaani org/t/
>
> I *think* this patch series is safe and was just pushed to make more
> people upgrade to newer versions faster
I retract this.

A HackerNews comment/thread [1] points this out:

# Set XZ_VERSION (and LIBLZMA_VERSION). This is needed to disable features
# that aren't available in old XZ Utils versions.
eval "$($XZ --robot --version)" || exit

That is indeed scary -- exactly the kind of thing that sort of makes
sense in isolation (xz --robot --version outputs some environment
variables) and then just becomes a gadget for exploitation if xz were to
start outputting something different there.

[1] https://news.ycombinator.com/item?id=39869715


Vegard