[xz] Remove JiaT75 as a contact, determine correct contacts

[Zenexer]

Given that the recent backdoor of xz/libzma is being attributed to the GitHub account @JiaT75, their contact info should probably be removed from google/oss-fuzz and the correct contacts should be determined.

References:

• https://www.openwall.com/lists/oss-security/2024/03/29/4
• https://news.ycombinator.com/item?id=39865810

[Zenexer]

This should almost certainly be reverted: 6403e93

[Zenexer]

cc @Larhzu

[jonathanmetzman]

Thanks. I've removed the account as a contact and I've also (temporarily?) disabled the projects out of an abundance of caution.
So far as I can tell, OSS-Fuzz is not been impacted by the compromise of the xz source distribution or the patches the contributor submitted to OSS-Fuzz.

1. OSS-Fuzz runs project (third party, such as xz) code in a sandboxed environment and without privileges. Malicious projects cannot harm other users of OSS-Fuzz or steal their bugs/testcases.
2. OSS-Fuzz pulled the source code for xz and xz-java from the git repos. As far as I can tell, only the tarballs were compromised, not the repos.
3. OSS-Fuzz did not find any interesting testcases or vulnerabilities in xz or xz-java. So adding themselves as contact did not give them access to anything important.

[marekr]

This PR should potentially be reverted #10667 because it was basically done to hide the exploit which was done through ifunc resolvers lol

[jonathanmetzman]

Interesting, I've removed the projects from oss-fuzz for now, but we should make sure to do this., if/when we reinstate the projects.
Could you explain how this PR hid the exploit? Was the PR malicious?

[marekr]

Interesting, I've removed the projects from oss-fuzz for now, but we should make sure to do this. Could you explain how this PR hid the exploit? Was the PR malicious?

The exploit uses ifuncs based on the openwall report

The backdoor initially intercepts execution by replacing the ifunc resolvers
crc32_resolve(), crc64_resolve() with different code, which calls
_get_cpuid(), injected into the code (which previously would just be static
inline functions). In xz 5.6.1 the backdoor was further obfuscated, removing
symbol names.

[jonathanmetzman]

Appreciate it. Just curious, is it possible the issue would have been found by a sanitizer were it not for this PR? I don't have an understanding of the backdoor yet.

[Zenexer]

Yes, that seems to be the consensus. Allegedly, the threat actor went to great lengths to circumvent sanitizers. I haven't verified this claim myself.

[jonathanmetzman]

Yes, that seems to be the consensus. Allegedly, the threat actor went to great lengths to circumvent sanitizers. I haven't verified this claim myself.

Wow, I'm surprised fuzzing could have found a backdoor.

[jonathanmetzman]

I also disabled liblzma for now though I suspect the version running on OSS-Fuzz was not compromised: #11762

[vielmetti]

CVE-2024-3094 is the associated CVE.

[dirkmueller]

Appreciate it. Just curious, is it possible the issue would have been found by a sanitizer were it not for this PR? I don't have an understanding of the backdoor yet.

The backdoor is part of a test file. It is a precompiled binary object that is being linked into the binary if it was built from the published tarball rather than git and only if a large number of specific conditions are passing. The conditions were amongst other things checking whether it's a debian or rpm package build. A plain build will not activate the backdoor.

While turning off ifunc is another way to protect the exploit from unpacking, in the backdoors current form it would not be necessary. Maybe it was necessary in a previous version of the backdoor that wasn't actually committed.

[acook]

Just some additional information:

It looks like the Larhzu account was added after JiaT75, and was created on the same day it was added to the Tukaani project (December 12, 2022). Both JiaT75 and Larhzu's accounts have been suspended by Github.

Edited to add:

To be clear, I am not accusing any person in particular, that is why I did not use full names. These are accounts that may have been compromised or misused.

Either way I think an abundance of caution should be exercised about who is a reliable point of contact until someone can verify them.

hansjans162 is still active on Github today, their account was created May 17, 2023. Thank you to DanielRuf for pointing this one out. hansjans162 made their account private during the fiasco today (understandably) but I was able to confirm the date during a time when it was made public again. They are credited with introducing the IFUNC code that was later misused by JiaT75. This does not mean that they introduced it intentionally for that purpose, IFUNC is a legitimate GCC extension that allows optimized code on for multiple platforms in a single binary.

[Zenexer]

That means #9960 was never approved by the previous maintainer. @jonathanmetzman, you may want to look into whether that has happened for other projects.

[thesamesam]

Please be careful. Larzhu is a long-term maintainer of xz-utils and xz-utils migrated to github a little while ago. It is not therefore unreasonable that accounts got made around the same time.

There is a lot going on here, speculation is making things harder.

[Traneptora]

For context, Lasse has been working on XZ for decades, long before the github account got created. See this as an example:

https://sourceforge.net/p/sevenzip/discussion/45797/thread/09814bb2/?limit=25#d81a

[Zenexer]

That being said, @JiaT75 was also an active maintainer.

Here's where an email attributed to @Larhzu was added: #1919

It references this: https://www.mail-archive.com/[email protected]/msg00307.html

Disable CRC check and add memory limit during decoder initialization

I seem recall a discussion attributing that exact patch to the threat actor in question.

There's inevitably going to be confusion and speculation. It would be best to figure out one responsible, known-good maintainer for xz and let them specify any other known-good maintainers.

Should that be @Larhzu? Do we know that the GitHub account is actually Lasse?

[DanielRuf]

@Traneptora hm, where do you see, that both users were created in 2022? For me it seems the GitHub user hansjansen was created in May 2023. And the other in 2022.

[marekr]

Yes, that seems to be the consensus. Allegedly, the threat actor went to great lengths to circumvent sanitizers. I haven't verified this claim myself.

Per Fedora dev list
https://lists.fedoraproject.org/archives/list/[email protected]/message/YTOGJVBNOSW7FSEE7B35GETS25KFPKBO/

(1) We built 5.6.0 for Fedora 40 & 41. Jia Tan was very insistent in
emails that we should update.

(2) We got reports later of a valgrind test failure. I also saw it
myself in my own projects that use liblzma. We notified Jia Tan of
this.

(3) Since the valgrind failure pointed to something with ifuncs, using
'./configure --disable-ifuncs' was used to fix this in F40 & F41.

(4) xz 5.6.1 was released with a fix for the valgrind failure.

Lol. I suppose this is might be why the disable-ifuncs got passed to oss-fuzz

[cwegener]

There's inevitably going to be confusion and speculation. It would be best to figure out one responsible, known-good maintainer for xz and let them specify any other known-good maintainers.

Should that be @Larhzu? Do we know that the GitHub account is actually Lasse?

At the moment, there is no active Github account available that would qualify.

tukaani-project/xz#92 (comment)

[DanielRuf]

@desu-anon I doubt that, the PR in the other repo is coincidence and there was no 1password takeover.

People are quick to jump to conclusions.

jamespfennell/xz#2 (comment)

[Zenexer]

I think we're probably moving well beyond the scope of this issue now. My intention was to find a responsible maintainer. From what I've gathered, that appears to be Lasse, although I'm unable to verify that the GitHub account claiming to represent him is actually him. I have other work I need to do and don't have enough knowledge of this project to make such a call.

[hhartzer]

I'm not confident about this, either. I did find this, however.

plougher/squashfs-tools#276

If you check out @Larhzu's fork/branch, the commit has his email address, and the commit on Github references the account, so it appears that the account is under his email address.

So it would seem to probably match, but everything is suspect at this point. I'm hoping Lasse's email isn't compromised.

[cwegener]

Well. Aaand Microsoft Thanos-snapped the project out of existence ... nice one. Good job. /s

[Daniel15]

Well. Aaand Microsoft Thanos-snapped the project out of existence ... nice one. Good job. /s

They have a policy that malware can't be distributed using Github so they've probably just shut down the repo until they figure out who's actually maintaining it and who can audit and remove the malicious code.

[evrial]

Until the xz project will be audited it should be removed from existence

[Zenexer]

There hasn't been any indication that any accounts were compromised. The remaining question I had was whether @Larhzu was actually created by and controlled by Lasse, but he's since stated that it's his account: https://tukaani.org/xz-backdoor/

I haven't seen any reasonable claims that takaani.org is compromised, so I'm inclined to trust that claim. Reverting the commit that added Jia Tan as a contact should be sufficient to close this issue.

[Zenexer]

Until the xz project will be audited it should be removed from existence

That's outside the scope of this project and issue.

[jonathanmetzman]

There hasn't been any indication that any accounts were compromised. The remaining question I had was whether @Larhzu was actually created by and controlled by Lasse, but he's since stated that it's his account: https://tukaani.org/xz-backdoor/

I haven't seen any reasonable claims that takaani.org is compromised, so I'm inclined to trust that claim. Reverting the commit that added Jia Tan as a contact should be sufficient to close this issue.

Thanks Zenexer. I think we will eventually give control back to Lasse if he wants. But I assume he has more important things to deal with now. I agree we can close this issue.