Avatar
Dr. Hax 1y ago

The xz package was backdoored, and the payload appears to be targeting SSH on x86_64 Fedora and Debian.

What you need to know:

- The backdoored version did not make it into any stable distros

- It was caught about a month after it was introduced

- It did make it into some bleeding edge distros (e.g. Debian's unstable branch: sid)

- It only affected the binary releases, so if you build from source, you were safe from this one

- It was only caught because the backdoor caused some tests to take a half second longer, someone noticed this and decided to investigate why

Get the technical details directly from the person who discovered it: https://www.openwall.com/lists/oss-security/2024/03/29/4

Reply to this note

Please Login to reply.

Discussion

Avatar
Dr. Hax 1y ago

There are plenty of lessons for attackers herr in this case study, but not much new for defenders. It just reenforces things security professionals have been saying for a long time.

1. Building from source is safer than downloading binaries

2. Reproducable builds can help spot differences between the source and binaries

3. Don't run services that you don't actually need (like SSH)

4. Make your systems as stripped down as possible (complexity is the enemy)

5. Compartmentalizatiton

6. Set up automated detection and response

7. Network segmentation (e.g. only allow SSH from an admin network)

8. It's better to build software that doesn't require constant updates (so there's more time to give scrutiny to the changes that are made)

9. Source code scanners and manual audits are good but not sufficient on their own

10. Many backdoors will have side channels (like performance issues) that can give them away. However, because of constant updates and complexity of most software nowadays, there are tons of other opportunities of performance issues to crop up. Also, some backdoors don't have a noticable performance impact

It's all pretty standard stuff here.

nostr:nevent1qqsppca5hst8f6ew34l8qzsnr654m0cc7cd04xmgzpad2gyaxfd4qcqpz9mhxue69uhkummnw3e82efwvdhk6q3q6v82nr4xt62nlydtj0mtxr49r6enc5r0sl2f7cq2zwdw7q92j5gsxpqqqqqqz9ankwg

Avatar
Dr. Hax 1y ago

I like how the beave reacted to that poat with a party icon. 🤣

Also, I'm not tagging them because #Amethyst still crashes when I try to tag someone. And before someone tells me that the crash is my fault because I use the "wrong" keyboard, sod off pal. I should have the #freedom to use whatever keyboard I want and not have tagging someone break, and also, it happens with the stock Android keyboard so I assure you, it's an Amethyst problem, not a me problem. v0.85.3-fdroid

Avatar
NaturalNerd 1y ago

Amethyst also crashes for me when I try to tag someone

Avatar
Dr. Hax 1y ago

It's been a known issue for months, but fixing it doesn't seem like a priority.

https://github.com/vitorpamplona/amethyst/issues/757

In fairness, I also am one of those people who has not been fixing it. But I just made a comment on that ticket to try to help find the bug in the code.

If anyone else can jump in with helpful comments on that ticket, please do. Or even just give the reporter a thumbs up to show how many people are affected (and also have a github account, and are willing to tie that account to being an Amethyst user).

Avatar
NaturalNerd 1y ago

I appreciate all the work the devs are doing. So many good ideas, how do you prioritize?

How can a non developer like me best contribute? Perhaps creating a bounty for the things I want.

We all have ideas, its up to the developers to choose what to focus on with 'volunteer' time. I appreciate you developing things you want instead of making more money developing elsewhere.

Avatar
Dr. Hax 1y ago

Here are dome ways non-developers can help:

Give issues that affect you a thumbs up on the issue tracker (GitHub in this case). Same for feature requests on the issue tracker. This shows the developers what things people want them to work on. They may not do so, but it enables them to make an informed decision.

On a related note, don't post comments like "this affects me too" on the issue tracker. A thumbs up indicates this and having a long list of comments like that risks people missing something important.

Help with testing and add any details that are missing. Steps to reproduce the issue are critical. Other examples: "this bug doesn't affect Android 13 and below" or "introduced in version xyz".

Be concise with your comments.

Link related issues together. Often it's helpful to know about other issues when a developer is already in that section of the code working on something else. Plus, it can help avoid making one problem worse when fixing another.

Creating a bounty is a good one, if you can afford it.

Spread the word about the project. I know this one sounds cheesy, but the more users a project has, the more likely it is that additional people will help with all of the things above (or people you share it with might be developers who can help with the code).

Avatar
NaturalNerd 1y ago

Great detailed response, thanks.

Avatar
trosso19 1y ago

Thanks for this! I'm always wary about posting issues on github for fear of being unhelpful or spamming the devs. Will thumbs up from now on

Avatar
ndr 1y ago

I'm not fully agree with that. You said:

~~~

What you need to know:

- It only affected the binary releases, so if you build from source, you were safe from this one

~~~

The backdoored xz was from upstream github, and was ported to Debian and fedora by building from source ... Also the backdoor get added to binarys by compiling it from source, since the malware is offuscaded not at the source by it is at side files included during compiling

Then I understood that it will only trigger at x86_64 , also if vulnerable xz packages were included on macosx brew .. That run almost arm architecture

Avatar
Alex 1y ago

The CVE mentions that part of the backdoor was not in the source code. That part was in release tarballs created by the attacker. https://tukaani.org/xz-backdoor/ I don’t get how this stuff gets included in Debian and Fedora. I guess they pull in tar balls too.

Avatar
Dr. Hax 1y ago

I was also very surprised/confused by that. But searching salsa.debian.org for liblzma doesn't turn anything up. I'm not sure why that one isn't built from source. 🤔🤷‍♂️

Avatar
Dr. Hax 1y ago

You aren't disagreeing with me, you are disagreeing with the person who discovered it.

Feel free to follow the link I provided and read what the person who discovered it said.

Avatar
ndr 1y ago

Yes, you was right. He said that the backdoor was inside (partially?) such tar files .. what is confusing me now is that he said also that it get triggered at configure and so at compiling time ... And probably I don't fully know the process from where other distros (fedora and Debian) use xz source to build distro packages .. So probably I would need to look at such stuff .. Were such tar files sources or binary ready compiled files ? .. Need to give a look into ...

Avatar
Alex 1y ago

😍

Avatar
Dr. Hax 1y ago

Some updates on the payload:

- it's not an authentication bypass, it's remote code execution (RCE)

- the code to be executed is provided in the public key (very clever!)

- it requires the attacker's private key to exploit

- even of an attack were captured, it could not be replayed on another machine

For more details, see my source: https://bsky.app/profile/did:plc:x2nsupeeo52oznrmplwapppl/post/3kowjkx2njy2b

nostr:nevent1qqsppca5hst8f6ew34l8qzsnr654m0cc7cd04xmgzpad2gyaxfd4qcqppamhxue69uhkummnw3ezumt0d5pzp5cw4x82vh5487g6hylkkv82284n83gxlp75nasq5yu6auq249g3qvzqqqqqqyf4l3z6