Open jzarnett opened 3 months ago
And yet I think it was discovered while performance profiling!
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 https://github.com/jzarnett/ece459/issues/99#issuecomment-2035825403, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOKE5QZHB75DQXB56QCF7DY3SJWRAVCNFSM6AAAAABFWEROASVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZVHAZDKNBQGM . You are receiving this because you commented.Message ID: @.***>
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.
...
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.