xz vulnerability

[jzarnett]

No description provided.

[patricklam]

https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/
https://infosec.exchange/@fr0gger/112189232773640259

Not sure it's so related to perf issues directly though.

[jzarnett]

And yet I think it was discovered while performance profiling!

[patricklam]

True, I'd read that too.

…

On Thu, Apr 4, 2024, 12:59 PM Jeff Zarnett ***@***.***> wrote: And yet I think it was discovered while performance profiling! — Reply to this email directly, view it on GitHub <#99 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOKE5QZHB75DQXB56QCF7DY3SJWRAVCNFSM6AAAAABFWEROASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZVHAZDKNBQGM> . You are receiving this because you commented.Message ID: ***@***.***>

[h365chen]

Here's some context from the original thread

https://www.openwall.com/lists/oss-security/2024/03/29/4

== Analyzing the injected code ==

I am not a security researcher, nor a reverse engineer. There's lots of
stuff I have not analyzed and most of what I observed is purely from
observation rather than exhaustively analyzing the backdoor code.

To analyze I primarily used "perf record -e intel_pt//ub" to observe where
execution diverges between the backdoor being active and not. Then also gdb,
setting breakpoints before the divergence.

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.

These functions get resolved during startup, because sshd is built with
-Wl,-z,now, leading to all symbols being resolved early. If started with
LD_BIND_NOT=1 the backdoor does not appear to work.

...