Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 30 Mar 2024 05:15:09 +0100
From: "Rein Fernhout (Levitating)" <>
Cc: Solar Designer <>, Andres Freund <>
Subject: Re: backdoor in upstream xz/liblzma leading to ssh
 server compromise

Hey Andres,

I missed the fact that you had already stated which version the .o was 
Thanks for clearing up some confusion on my side.
I did copy the wrong file (linked with crc64_fast.c).

I now managed to copy ./liblzma_la-crc64-fast.o before it was deleted.
With both versions my copy matches yours.

Also, I am sorry for not compressing the file earlier! I realized it 
just as I hit Send.

PS. It seems like Github has taken down the xz repositories.
The source can still be pulled from
And the malicious tarballs are archived by

Kind regards,

On 2024-03-30 03:04, Andres Freund wrote:
> Hi,
> On 2024-03-30 01:08:22 +0100, Rein Fernhout (Levitating) wrote:
>> > Andres, maybe you (or Florian or someone else) can post the .o file from
>> > 5.61 as well (gzipped just like the previous one, please)?
>> I think the attached liblzma_la-crc64-fast.o is taken from 5.6.1.
>> I compiled 5.6.1 and ended up with a nearly identical object file.
> I don't think so - while it was extracted by Florian, not me, I just
> re-extracted it from 5.6.0 and got the same result.
>> When I compiled 5.6.0 I got a larger object file with additional 
>> symbols
>> crc64_generic, crc64_arch_optimized and crc64_resolve.
> I think it may just be confusion from the script renaming files. The 
> symbols
> you mention come from the script compiling 
> src/liblzma/check/crc64_fast.c
> after making some small changes, to call into the added _get_cpuid().  
> Whereas
> the attached file was the .o file that was, in very obfuscated form, 
> committed
> to the repository.
> The script is quite sneaky, it
> 1) extracts ./liblzma_la-crc64-fast.o from the archive
> 2) copies .libs/liblzma_la-crc64_fast.o .libs/liblzma_la-crc64-fast.o 
> (note
>    the .libs)
> 3) compiles and links the modified crc64_fast.c file together with the
>    extracted ./liblzma_la-crc64-fast.o, outputting to
>    .libs/liblzma_la-crc64_fast.o, using -r
> 4) does 2) for the 32 bit version
> 5) compiles the modified crc32_fast.c, outputting to
>    .libs/liblzma_la-crc32_fast.o
> 6) links the shared library
> 7) if compilation fails, it moves .libs/liblzma_la-crc{64,32}-fast.o 
> back to
>    their original name, I guess to removing "evidence" of the modified 
> output
> 8) removes
>    ./liblzma_la-crc64-fast.o,
>    .libs/liblzma_la-crc64-fast.o,
>    .libs/liblzma_la-crc32-fast.o
> If you found crc64_generic etc in liblzma_la-crc64-fast.o, you must 
> have used
> the one from .libs/ somehow?
> I'm attaching ./liblzma_la-crc64-fast.o for both 5.6.0 and 5.6.1. These 
> are
> the files extracted from the .xz file, and should not have symbols for
> crc64_arch_optimized, crc64_resolve, crc64_generic but will have stuff 
> like
> _get_cpuid, .crc64_generia.
> When the backdoor is not active .libs/liblzma_la-crc64_fast.o has only 
> few
> symbols, crc64_generic, crc64_arch_optimized, crc64_resolve.
> Greetings,
> Andres Freund

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.