undefined | Better HN

0 points0x02y ago0 comments

Just because macs don't use systemd, doesn't mean the backdoor won't work. The oss-sec post talks about liblzma having backdoors in crc32_resolve() and crc64_resolve() and that it has not been fully reversed. This could perhaps affect more than just sshd on x86-64 linux?

0 comments

anarazel2y ago

> Just because macs don't use systemd, doesn't mean the backdoor won't work.

Practically speaking it can't - For one the script injected into the build process tests that you're running on x86-64 linux, for another, the injected code is elf code, which wouldn't link on a mac. It also needs to manipulate dynamic linker datastructures, which would also not work the same on a mac.

> This could perhaps affect more than just sshd on x86-64 linux?

This however is true - /usr/sbin/sshd was the only argv[0] value that I found to "work", but it's possible there are others. "/usr/sbin/sshd" isn't a string directly visible in the injected code, so it's hard to tell.

stephenr2y ago

The article explains numerous concurrent conditions that have to be met for the backdoor to even be activated (at build time, not runtime), which combined make it extremely unlikely this will affect SSH on macOS:

- linux

- x86-64

- building with gcc & the GNU linker

- part of a .deb or .rpm build

Add to that, as the article explains: openssh does not directly use liblzma, the only reason SSH is affected at all, is because some Linux Distros patch openssh to link it against systemd, which does depend on liblzma.

Could it affect things other than SSH on a Mac? Unlikely. The compromise was introduced in 5.6.0, but macOS Sonoma has 5.4.4 (from August last year).

j / k navigate · click thread line to collapse