News for hackers. Stuff that matters.
Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by amscanne on Saturday March 30, 2024 @08:14PM (#39879982)
There is no ‘system()’ syscall, and fork/exec would be extremely common for opensshd — it’s what it does to spawn new shells which go on to do anything.

I’m not arguing with the point, but this is a great place to hide — very difficult to have meaningful detection rules even for a sophisticated sysadmin.

Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by ivlad on Sunday March 31, 2024 @12:12AM (#39881367)
This would be execve() that did not go through PAM dance and end up being privileged process.

I _think_ it’ll look very different in ps —-forest output.

Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by amscanne on Sunday March 31, 2024 @01:41AM (#39881748)
It’s true that there’s a precise set of circumstances that would be different for the RCE (the lack of a PAM dance prior, same process group & session, no allocation of a pseudo-terminal, etc.). My point was merely that I don’t think they are commonly encoded in rule sets or detection systems.

It’s certainly possible, but my guess is sshd is likely to have a lot of open policy. I’m really curious if someone knows different and there are hard detection for those things. (Either way, I bet there will be in the future!)

Re:XZ backdoor: "It's RCE, not auth bypass, and gated/unrepl... by ivlad on Sunday March 31, 2024 @02:53AM (#39882021)
I am trying to figure out if auditctl is expressive enough to catch unexpected execve() from sshd: basically anything other than /usr/bin/sshd (for privsep) executed with auid=-1 should be suspicious.