“The maintainers of libcolorpicker.so can’t be the only thing that stands between your critical infrastructure and Russian or Chinese intelligence services.”
lcamtuf.substack.com/p/oss-backdo...
lcamtuf.substack.com/p/oss-backdo...
OSS backdoors: the folly of the easy fix
Intelligence agencies and Big Tech, not hobbyists, should shoulder the responsibility for preventing the next xz-style hack.
lcamtuf.substack.com
April 2, 2024 at 1:49 AM
“The maintainers of libcolorpicker.so can’t be the only thing that stands between your critical infrastructure and Russian or Chinese intelligence services.”
lcamtuf.substack.com/p/oss-backdo...
lcamtuf.substack.com/p/oss-backdo...
Reposted by John Wood
I'm watching some folks reverse engineer the xz backdoor, sharing some *preliminary* analysis with permission.
The hooked RSA_public_decrypt verifies a signature on the server's host key by a fixed Ed448 key, and then passes a payload to system().
It's RCE, not auth bypass, and gated/unreplayable.
The hooked RSA_public_decrypt verifies a signature on the server's host key by a fixed Ed448 key, and then passes a payload to system().
It's RCE, not auth bypass, and gated/unreplayable.
This might be the best executed supply chain attack we've seen described in the open, and it's a nightmare scenario: malicious, competent, authorized upstream in a widely used library.
Looks like this got caught by chance. Wonder how long it would have taken otherwise.
Looks like this got caught by chance. Wonder how long it would have taken otherwise.
Woah. Backdoor in liblzma targeting ssh servers.
www.openwall.com/lists/oss-se...
It has everything: malicious upstream, masterful obfuscation, detection due to performance degradation, inclusion in OpenSSH via distro patches for systemd support…
Now I’m curious what it does in RSA_public_decrypt
www.openwall.com/lists/oss-se...
It has everything: malicious upstream, masterful obfuscation, detection due to performance degradation, inclusion in OpenSSH via distro patches for systemd support…
Now I’m curious what it does in RSA_public_decrypt
March 30, 2024 at 5:13 PM
I'm watching some folks reverse engineer the xz backdoor, sharing some *preliminary* analysis with permission.
The hooked RSA_public_decrypt verifies a signature on the server's host key by a fixed Ed448 key, and then passes a payload to system().
It's RCE, not auth bypass, and gated/unreplayable.
The hooked RSA_public_decrypt verifies a signature on the server's host key by a fixed Ed448 key, and then passes a payload to system().
It's RCE, not auth bypass, and gated/unreplayable.
Reposted by John Wood
Woah. Backdoor in liblzma targeting ssh servers.
www.openwall.com/lists/oss-se...
It has everything: malicious upstream, masterful obfuscation, detection due to performance degradation, inclusion in OpenSSH via distro patches for systemd support…
Now I’m curious what it does in RSA_public_decrypt
www.openwall.com/lists/oss-se...
It has everything: malicious upstream, masterful obfuscation, detection due to performance degradation, inclusion in OpenSSH via distro patches for systemd support…
Now I’m curious what it does in RSA_public_decrypt
oss-security - backdoor in upstream xz/liblzma leading to ssh server compromise
www.openwall.com
March 29, 2024 at 4:49 PM
Woah. Backdoor in liblzma targeting ssh servers.
www.openwall.com/lists/oss-se...
It has everything: malicious upstream, masterful obfuscation, detection due to performance degradation, inclusion in OpenSSH via distro patches for systemd support…
Now I’m curious what it does in RSA_public_decrypt
www.openwall.com/lists/oss-se...
It has everything: malicious upstream, masterful obfuscation, detection due to performance degradation, inclusion in OpenSSH via distro patches for systemd support…
Now I’m curious what it does in RSA_public_decrypt