RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

Post by nubinetwork » Mon, Jul 01, 2024, 10:11 AM UTC

0x0 wrote: post #4

Patch out for Debian 12; Debian 11 not affected. https://security-tracker.debian.org/tracker/CVE-2024-6387

Post by megous » Mon, Jul 01, 2024, 10:16 AM UTC

ale42 wrote: post #32

megous wrote: post #2

In our experiments, it takes ~10,000 tries on average to win this race condition, so ~3-4 hours with 100 connections (MaxStartups) accepted per 120 seconds (LoginGraceTime). Ultimately, it takes ~6-8 hours on average to obtain a remote root shell, because we can only guess the glibc's address correctly half of the time (because of ASLR). MaxStartups default is 10

Such an amount of connections should anyway trigger all possible logging & IDS systems, right?

Post by fanf2 » Mon, Jul 01, 2024, 10:17 AM UTC

djmdjm wrote: post #28

fanf2 wrote: post #16

It’s also worth reading the release notes https://www.openssh.com/releasenotes.html This is actually an interesting variant of a signal race bug. The vulnerability report says, “OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.” So a signal-safety mitigation encouraged OpenBSD developers to put non-trivial c…

Theo de Raadt made an, I think, cogent observation about this bug and how to prevent similar ones: no signal handler should call any function that isn't a signal-safe syscall. The rationale is that, over time, it's too way easy for any transitive call (where it's not always clear that it can be reached in signal context) to pick up some call that isn't async signal safe.

Post by FiloSottile » Mon, Jul 01, 2024, 10:20 AM UTC

fanf2 wrote: post #23

FiloSottile wrote: post #20

Interestingly, the RCE fix was "smuggled" in public almost a month ago. When PerSourcePenalties are enabled, sshd(8) will monitor the exit status of its child pre-auth session processes. Through the exit status, it can observe situations where the session did not authenticate as expected. These conditions include when the client repeatedly attempted authentication unsucessfully (possibly indicating an attack against…

That's not the RCE fix, this is the RCE fix https://news.ycombinator.com/item?id=40843865 That's a previously-announced feature for dealing with junk connections that also happens to mitigate this vulnerability because it makes it harder to win the race. Discussed previously https://news.ycombinator.com/item?id=40610621

    On June 6, 2024, this signal handler race condition was fixed by commit
    81c1099 ("Add a facility to sshd(8) to penalise particular problematic
    client behaviours"), which moved the async-signal-unsafe code from
    sshd's SIGALRM handler to sshd's listener process, where it can be
    handled synchronously:

      https://github.com/openssh/openssh-portable/commit/81c1099d22b81ebfd20a334ce986c4f753b0db29

    Because this fix is part of a large commit (81c1099), on top of an even
    larger defense-in-depth commit (03e3de4, "Start the process of splitting
    sshd into separate binaries"), it might prove difficult to backport. In
    that case, the signal handler race condition itself can be fixed by
    removing or commenting out the async-signal-unsafe code from the
    sshsigdie() function

Post by lenlorijn » Mon, Jul 01, 2024, 10:21 AM UTC

CJefferson wrote: post #21

This is a really good find. One thing which (as an independant person, who isn't doing any of the work!) is it often feels like in order to 'win', people are expected to find a full chain which gives them remote access, rather than just finding one issue, and getting it fixed / getting paid for it. It feels to me like finding a single hole should be sufficient -- one memory corruption, one sandbox escape. Maybe at th…