[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <91ed173a97361c7cfa5a2e9e7e742956@purelymail.com>
Date: Sat, 30 Mar 2024 05:15:09 +0100
From: "Rein Fernhout (Levitating)" <me@...itati.ng>
To: oss-security@...ts.openwall.com
Cc: Solar Designer <solar@...nwall.com>, Andres Freund <andres@...razel.de>
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
from.
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 https://git.tukaani.org/.
And the malicious tarballs are archived by archive.org.
Kind regards,
Rein
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.
