Re: CVE-2023-48795: Backporting strict key exchange to older libssh
Hi.
Thank you for all the good questions! I will try to reply inline.
On Sat, Dec 30, 2023 at 8:41 PM Sean Whitton <spwhitton@spwhitton.name> wrote:
>
> Hello,
>
> I am working to backport the fix for CVE-2023-48795 to libssh 0.8.7,
> as part of Debian's Long Term Support effort, funded by Freexian SARL.
> (I will later be seeking to backport the fix to 0.7.3 and 0.6.3 too, as
> part of Freexian's Extended Long Term Support effort.)
To save you some time, I think you will not need to do this for 0.7 and older as
these do not support neither chacha20 cipher nor the etm macs so these should
not be affected.
> I have two queries about this, if I may.
>
> (1) These older libssh do not include the rekeying as implemented in
> commit 58cae236. Is that rekeying necessary for the strict key
> exchange to be effective?
No. The Rerekying is not necessary for exploiting the CVE-2023-48795.
The exploit can happen only during the first key exchange when the messages
are not yet encrypted.
Note, that even though the libssh 0.8 does not implement the automatic
invocation of rekeying after specific amount of time/transferred data,
the rekeying can be triggered by the other party as described by the
protocol (but there might be some bugs as we do not have test coverage
for this in the old versions as far as I know).
> (2) Does anyone have a utility that tests the strict key exchange?
> Or, does the regular test suite already exercise the relevant code?
> I'm asking because the vulnerability scanner on terrapin-attack.com
> only seems to check for support of strict key exchange, not whether
> it actually works.
I am not aware of any other tool than the one created by the researchers.
But generally, if you get both of the client and server supporting the extension
(can be checked with the tool from terrapin-attack.com) and everything works
with the strict key exchange (running testsuite, executing some real-world/test
connections to other strict hosts), it works. If it would not, you
would get failures
on the protocol level.
The last resort might be reviewing the debug logs from libssh or the other peer,
making sure the sequence number is reset when running against some
known-to-be-good implementation, either current libssh or openssh. But again,
this mode requires both peers to reset the sequence numbers at the same time
and if this does not happen in one, the MACs will not match and the connection
will be terminated.
Hope it helps,
Jakub
Reply to: