:: Re: [DNG] CVE-2024-6387: regreSSHio…
Página Inicial
Delete this message
Reply to this message
Autor: Martin Steigerwald
Data:  
Para: dng
Assunto: Re: [DNG] CVE-2024-6387: regreSSHion bug in OpenSSH
Martin Steigerwald - 02.07.24, 09:30:15 CEST:
> Simon Walter - 02.07.24, 07:40:41 CEST:
> > Is this fixed upstream already?
>
> Like mentioned on the Debian CVE page, mentioned by Ludovic, I suppose
> yes.
>
> However the updated packages currently work around the issue:
>
> openssh (1:9.7p1-7) unstable; urgency=critical
>
> [ Salvatore Bonaccorso ]
> * Disable async-signal-unsafe code from the sshsigdie() function.
> This is a minimal workaround for a regression from CVE-2006-5051.
>
> -- Colin Watson <[…]> Mon, 01 Jul 2024 10:11:27 +0100


Posting my inofficial guidance on patching here as well. It will be much
easier to find in this thread as in yet another "Is this systemd?" thread.

Quite good english language description of the matter, originally
mentioned by Arnt:

Nasty regreSSHion bug in OpenSSH puts roughly 700K Linux boxes at risk

Full system takeovers on the cards, for those with enough patience to pull
it off

Connor Jones

Mon 1 Jul 2024 // 14:01 UTC

https://www.theregister.com/2024/07/01/regresshion_openssh/

From above article:

"Damien Miller, founder of the portable OpenSSH project and maintainer
since 1999, said in an online discussion that anything running glibc is
probably vulnerable. Systems with 32-bit architectures have been proven to
be so, and 64-bitters are likely at risk too."


From what I understand Devuan thus is affected as well. Patch your systems!

Devuan 5 aka Daedalus (1:9.2p1-2+deb12u3) and Devuan Ceres (1:9.7p1-7)
have patched packages already. Devuan Excalibur / Testing to come soon,
but you can download the package for Devuan Unstable and install it on
Devuan Testing. Just switch your sources.list temporarily to Ceres.
Install the OpenSSH packages and you run a patched version (1:9.7p1-7).
Remember to switch back to Testing afterwards. Again Alpine and Void would
not be affected.

I recommend to reduce MaxSessions in /etc/ssh/sshd_config to say 3 or so on
unpatched systems. And not only on unpatched systems. The estimate of 4-8
hours or even longer is for systems which allow 100 sessions as far as I
read. Debian usually restricts to 10 sessions. if you go even lower, an
attacker needs a really long time to successfully attack with an approach
like this. So given the time needed to exploit with 10 concurrent sessions
or less… this vulnerability may be a bit overrated, *in case* you patch
your systems soon. If you leave them vulnerable for longer periods of
time… that is your risk to take.

But of course it is indeed severe. Root access by an remote attack it to
be taken serious. Just I don't think its wise to panic around like crazy.
Just do the updates!

Best,
--
Martin