#959881 libssh2-1: ECDSA and memory leaks

Package:
libssh2-1
Source:
libssh2
Description:
SSH2 client-side library
Submitter:
Benjamin Riefenstahl
Date:
2022-09-20 21:30:03 UTC
Severity:
normal
#959881#5
Date:
2020-05-06 13:10:41 UTC
From:
To:
Dear Maintainer,

We are using libcurl for SFTP in our own software.  Libcurl in turn
relies on libssl2 for this feature.  We already use libcurl for HTTP and
HTTPS, so we would like to stick with that level so we have more common
code.

We have a tool containing our code for testing.  With that we tested
support for ECDSA client keys.  This works with the OpenSSH tool "sftp",
but not with our software.  When we compare the server debug log
(OpenSSH in debug mode, level debug3) with what we get from running the
sftp tool, the authentification sequence stops earlier, before reaching
success.

We also have a unit test that runs our code in a loop and that shows
memory leaks.

Scanning the changelogs of libssh2, it seems that there are important
updates for both of these problems in libssh2 in the current version
1.9.  So before investigating further, we would like to ask, when we can
expect that version to come to Debian and if there is something we can
do to help.

Regards,
Benjamin Riefenstahl, mecom GmbH
#959881#10
Date:
2020-12-07 12:58:22 UTC
From:
To:
Hello,
libssh2 1.9 has been uploaded to unstable, can you check if the problems
are fixed now?

/Nicolas
#959881#15
Date:
2021-02-09 15:45:43 UTC
From:
To:
Hi Nicolas,

Nicolas Mora writes:

Sorry for taking so long, I just now found the time to test this.  Sad
to say that both the memory leak and the problem with ECDSA still exist,
when I run our test in a container with Debian testing and libssh2-1
1.9.0-2.

I'm especially puzzled by the ECDSA key failure.  The OpenSSH server
seems to ok with the key (although it does say "Postponed publickey"
after "Accepted key"), so maybe this is a problem on the client side.
From libcurl I get the CURL error code 67 "Login denied".  I'm not sure
how to debug this, libcurl's debugging facilities do not give any output
here.  Is it possible to use libssh2_trace with libcurl and the Debian
packages?

Regards,
Benjamin Riefenstahl
#959881#20
Date:
2021-02-11 13:04:21 UTC
From:
To:
Hello,

Le 2021-02-09 à 10 h 45, Benjamin Riefenstahl a écrit :
Can you provide a sample code so I can reproduce the errors?

Therefore I can see the problem by myself and the bugs can be forwarded
upstream if necessary.

Thanks in advance

/Nicolas
#959881#25
Date:
2021-04-11 15:29:29 UTC
From:
To:
Just a minor update to the ECDSA test case, so that it does not require
the projetct to reside in a Git repository.
#959881#30
Date:
2021-04-11 15:07:06 UTC
From:
To:
Sorry this has taken so long.  I have now reduced our testcases to what
seems necessary for reproducing the problems.  This is in C++, I would
have to spend some more time with it to translate that into plain C, if
you need that.  We also use the base class cCURL.cpp with HTTP/REST and
that does not have the memory leak problem.

Usage after unpacking is just:

  $ make test              # Success
  $ make test+memory-leak  # Fail
  $ make test+ecdsa        # Fail

Prerequisites are GCC, OpenSSH server and of course libcurl-dev.
#959881#35
Date:
2021-04-18 15:43:56 UTC
From:
To:
I have done that now.

This stays all the same.  If you prefer you can use the binary
target/tSftp directly to test with your own SSH server.

I did two additional experiments based on the code:

* sftpcurl.c:sftp_upload: Commenting out the call to curl_easy_perform
  makes the memory leak go away, which verifies that the test setup and
  the resource management around the call do not leak.

* tSftp.c:test_curl_memory_leak: Moving the call to exit(1) from the
  inside of the loop to the end of the function shows that the one
  increase in memory is not a fluke but that every run through the
  function leaks memory.

Regards, benny
#959881#40
Date:
2021-04-19 15:41:52 UTC
From:
To:
I have just tested in a Docker container on sid and with that version
(libssh2-1 1.9.0-3) ECDSA works (makes sense when I look at the
changelog).  The memory leak is still there.
#959881#45
Date:
2021-05-08 15:30:18 UTC
From:
To:
I did some more digging and than made a bug report with Curl upstream
here: <https://github.com/curl/curl/issues/6990>.  This produced a
commit there that makes my test work much better.

The glibc function mallinfo still says that a couple of bytes go missing
now and than, but valgrind says it can't find anything.  I also repeated
the test 20000 times and watched the memory in htop and it didn't grow,
so I will assume this is an error with mallinfo.

Thank you for your attention and your patience.

Regards, benny
#959881#48
Date:
2021-08-31 16:44:04 UTC
From:
To:
This might be resolved with 1.9.0-3's switch to the openssl backend.
#959881#53
Date:
2022-04-26 10:59:48 UTC
From:
To:
Probably related, I see a memory leak occurring every time libssh2_session_handshake() is called, using libssh2-1:amd64 1.9.0-2 on Bullseye.

However, installing version 1.10.0-3 from Bookworm fixes (at least) this issue.  A zip containing a minimal example and the Valgrind output from Bullseye is attached.

As the bug makes libssh2 more or less unusable for long-running processes (where the leaks accumulate for each handshake), IMHO it might be worth to provide v. 1.10.0 for Bullseye.

Thanks, Albrecht.
#959881#58
Date:
2022-09-20 21:11:19 UTC
From:
To:
I suggest providing 1.9.0-3 (which has the gcrypt->openssl switch) for a bullseye point release.