Re: CVE-2023-48795: Backporting strict key exchange to older libssh

[Jakub Jelen]

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  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

Re: CVE-2023-6918: removal of unused evp functions & types

[Jakub Jelen]

Hi,
This CVE is about checking return code from the crypto library API
calls, which could fail and cause some unexpected behavior such as
usage of uninitialized memory, DoS, ... Our analysis did not show any
important exploitable code path (but it was in supported libssh
versions -- this might not be the case in older ones!).

The removed functions evp, evp_update, evp_final all return void so
they are not fixable with current singature. As always, we recommend
to update to the supported libssh version which has this fix already
backported. If you really need to use older libssh version, you will
likely have to fix these functions by
 * checking crypto library API calls results in these functions
 * returning the meaningful result from these functions
 * checking the return values from these evp() functions

In any case, if you do the backports anyway and you want somebody to
have a look into them, opening a merge request on gitlab would be
best. More eyes will see more issues and if there are more people
interested in these patches, it might save somebody some more time. We
can accept the changes, but we will likely not do release though.

Best regards,
Jakub Jelen

On Sun, Feb 25, 2024 at 6:17 AM Sean Whitton  wrote:
>
> Hello,
>
> Thank you again for the information in January regarding backporting the
> fix for CVE-2023-48795 to older libssh.  I am now working to backport
> the fix for CVE-2023-6918, and have a quick question.
> There is a commit labelled
>
> CVE-2023-6918: Remove unused evp functions and types
>
> but this is non-trivial to backport because the functions are not unused
> in the older libssh.  My question is, is there a security concern with
> these functions, or was this commit just tidying up?
>
> I'm asking because the commit message is prefixed with the CVE number,
> which makes me think it might be significant for the vulnerability.
>
> Thanks!
>
> --
> Sean Whitton