On Mon Jan 27, 2025 at 1:26 PM CET, G. Branden Robinson wrote: > At 2025-01-24T07:47:00+0100, Ingo Schwarze wrote: > [...] > > (1) In theory, the idea of a standardized approach to portability > > sounds good, so it's hard to argue with that. The problem is not the > > basic idea, but that gnulib is overzealous *and* overengineered to > > such an extent that the end result is nothing short of catastrophic. > > I don't know if I agree with this. It could be argued that OpenBSD > deliberately wraps itself in a lot of straight jackets, in the name of > security and other concerns. Witness that OpenBSD's own projects aren't > written to be portable to anything except OpenBSD itself. If you want > OpenSSH or LibreSSL on some other kernel, you must confine your > activities to a sort of portability anteroom. > > I don't condemn that arrangement; it's probably accomplishing what it > was meant to, as highlighted last year with the XZ Utils social > engineering attack. > [...]
Opinions about that vary; see <https://isopenbsdsecu.re/quotes/>. As far as the xz backdoor is concerned, it wouldn't have affected OpenBSD even if they used glibc and had no mitigations at all: To: oss-secur...@...ts.openwall.com Subject: backdoor in upstream xz/liblzma leading to ssh server compromise [...] == Affected Systems == The attached de-obfuscated script is invoked first after configure, where it decides whether to modify the build process to inject the code. These conditions include targeting only x86-64 linux: [...] Building with gcc and the gnu linker [...] Running as part of a debian or RPM package build: [...] == Observing Impact on openssh server == [...] openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma. [...] == Analyzing the injected code == [...] 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. [...] In the second invocation crc64_resolve() appears to find various information, like data from the dynamic linker, program arguments and environment. Then it perform various environment checks, [...] If the above decides to continue, the code appears to be parsing the symbol tables in memory. This is the quite slow step that made me look into the issue. Notably liblzma's symbols are resolved before many of the other libraries, including the symbols in the main sshd binary. This is important because symbols are resolved, the GOT gets remapped read-only thanks to -Wl,-z,relro. To be able to resolve symbols in libraries that have not yet loaded, the backdoor installs an audit hook into the dynamic linker, [...] It looks like the audit hook is only installed for the main binary. That hook gets called, from _dl_audit_symbind, for numerous symbols in the main binary. It appears to wait for "rsa_public_decr...@....plt" to be resolved. When called for that symbol, the backdoor changes the value of rsa_public_decr...@....plt to point to its own code. It does not do this via the audit hook mechanism, but outside of it. [...] After that the audit hook is uninstalled again. [...] == Impact on sshd == The prior section explains that rsa_public_decr...@....plt was redirected to point into the backdoor code. The trace I was analyzing indeed shows that during a pubkey login the exploit code is invoked [...] TL;DR: OpenSSH does not depend on xz in any way, but a patched version distributed by Debian et al. makes it an indirect run dependency, which enables the exploit. Also, the exploit is injected into the binary only when building Debian or RPM packages. ~ onf
