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

["Rein Fernhout (Levitating)" <me () levitati ng>]

The script attached by Andres was from 5.6.0.
I extracted the script from both versions and I can verify your diff.
I attached the two versions I extracted.

It definitely does look like the 5.6.1 version looks for 2 extra scripts 
to execute.
I don't get any matches on the greps either though.

For reference these are all the test files uploaded by Jia Tan, with 
commit hash and summary:

bad-3-corrupt_lzma2.xz     74b138d2a6529f2c07729d7c77b1725a8e8b16f1 
Tests: Update two test files.
bad-dict_size.lzma         cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0 
Tests: Add a few test files.
good-1-riscv-lzma2-1.xz    a67dcce6109c2f932a0a86abb0d7a95d3c31fb3e 
Tests: Update RISC-V test files.
good-1-riscv-lzma2-2.xz    a67dcce6109c2f932a0a86abb0d7a95d3c31fb3e 
Tests: Update RISC-V test files.
good-2cat.xz               cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0 
Tests: Add a few test files.
good-large_compressed.lzma 74b138d2a6529f2c07729d7c77b1725a8e8b16f1 
Tests: Update two test files.
good-small_compressed.lzma cf44e4b7f5dfdbf8c78aef377c10f71e274f63c0 
Tests: Add a few test files.

I also want to look more into the object file.

On 2024-03-30 13:14, Jonathan Schleifer wrote:
> (Sorry, I'm not subscribed to the list, and it seems the web interface 
> doesn't expose the message ID so that I could add the appropriate 
> headers, so this will probably not show up us as proper reply.)
>
> After reading this, I took a look at xz-5.6.1.tar.bz2 and extracted the 
> payload manually myself. The `sed \”r\n\” $gl_am_configmake` never 
> worked for me, so instead I replaced that with cat and could still get 
> the script extracted.
>
> However, the script I extracted has a diff: http://sprunge.us/okPUXN
>
> This seems to look for yet another test and if it exists extracts a 
> shell script from yet another test - before even checking any of the 
> abort conditions. I think the assumption "If you don't build an RPM / 
> deb, you're fine" probably does not hold as a result.
>
> If I run those greps manually, I have no matches. So this could mean 
> this is just future proofing for future tests to be checked in. 
> However, I suspect that this is because I extracted the script without 
> executing configure, so I'm guessing there is a transformation missing 
> that would transform these greps to something else that would then 
> match.
>
> Has anyone else looked into this in more detail? My impression is that 
> everybody went by the initial analysis, assumed they are safe and 
> didn't do any further reversing.
>
> Also I've looked at the .o that gets linked in. It's 88 KB in size and 
> uses misleading symbols: They are symbols that actually exist in 
> liblzma, but prefixed with .L, meaning they are local - and do 
> something else entirely than the name implies. I did some static 
> analysis, but then hit an indirect branch where I don't know where it 
> goes. In any case, 88 KB is a lot for just a backdoor in SSH, so I'm 
> wondering if it does more.
>
> I think there really needs to be more reverse engineering. Is there any 
> such effort? I think it would make sense to join forces and start a 
> group.

Attachment: injected-61.txt
Description:

Attachment: injected-60.txt
Description: