Emerald (she/her)Debian security amirite?
MNByChoiceThe slowness is on purpose.
(OP may know, but I don’t know if everyone does.)
The slowness is on purpose? To help identify the sshd in question to the attacker which nodes are compromised?
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.
That is from the original find. Not sure the relevance of it and this being proof for it being “on purpose”. But that is the origin of the slowness.
I doubt that was intentional, they would likely want to hide that latency but the CPU time required to scan everything just is what it is.
bsky.app/profile/…/3kowjkx2njy2b
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.
Filippo Valsorda (@filippo.abyssdomain.expert)
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. [contains quote post or other embedded content]
He’s talking about Debian’s slowness in getting new versions to stable, and how the meme ignores security backports.
Ohh that makes way more sense, thanks. I haven’t used Debian in like 10 years but it was obviously the same back then too.