Memory Leak created by Credentials creation via API

Building from Source and Advanced Topics Greenbone Management Protocol (GMP)
1

Hi,

We currently stumbled upon a memory leak in OpenVas when creating credentials using the GMP Python API.

To reproduce this issue we used the “create_credential” function in the Python library with the name, credential_type, login and password arguments. The password argument value though was ‘None’. Looking at the library code this puts an xml request together but with no password element added. This is then sent to using GMP protocol as a command.

We then detected the following error in the logs:

sd main:MESSAGE:2019-05-21 14h46.50 utc:9: openvassd 6.0.0 started
sd main:MESSAGE:2019-05-21 14h48.50 utc:202: Starts a new scan. Target(s) : 10.12.42.68, with max_hosts = 30 and max_checks = 10
sd main:MESSAGE:2019-05-21 14h48.50 utc:209: Testing 10.12.42.68 [209]
lib nasl:MESSAGE:2019-05-21 14h49.59 utc:4610: Function ssh_login called from ssh_proto_version.nasl: Failed to set SSH key type ‘ecdsa-sha2-nistp256’: Setting method: no algorithm for method “server host key algo” (ecdsa-sha2-nistp256)
lib misc:MESSAGE:2019-05-21 14h51.19 utc:8427: Function (null) called from http_header_value_format_string.nasl: Severe bug! Unhandled transport layer -1 (fd=1000000).
lib misc:MESSAGE:2019-05-21 14h51.19 utc:8427: Function http_recv_headers2 called from http_header_value_format_string.nasl: Severe bug! Unhandled transport layer -1 (fd=1000000).
lib misc:MESSAGE:2019-05-21 14h51.19 utc:8427: Function (null) called from http_header_value_format_string.nasl: Severe bug! Unhandled transport layer -1 (fd=1000000).
lib misc:MESSAGE:2019-05-21 14h51.19 utc:8427: Function http_recv_headers2 called from http_header_value_format_string.nasl: Severe bug! Unhandled transport layer -1 (fd=1000000).
lib misc:MESSAGE:2019-05-21 14h51.19 utc:8427: Function (null) called from http_header_value_format_string.nasl: Severe bug! Unhandled transport layer -1 (fd=1000000).
lib misc:MESSAGE:2019-05-21 14h51.19 utc:8427: Function http_recv_headers2 called from http_header_value_format_string.nasl: Severe bug! Unhandled transport layer -1 (fd=1000000).
lib misc:MESSAGE:2019-05-21 14h51.19 utc:8427: Function (null) called from http_header_value_format_string.nasl: Severe bug! Unhandled transport layer -1 (fd=1000000).

The last two lines keep appearing a loop and we get no response back so the connection on the client side times out.

This generates an infinite number of core files (until it hits the limit :slight_smile:)

Please let me know if I have added this issue in the wrong location so I can put in the right place. I suppose not providing a password element for creating credentials should respond with a failure and inform user to provide password rather than end up in a loop.

Thank you.

Malcolm

2

Sorry I don’t understand what you are doing here exactly. Do you create a credential via python-gvm and are using it as a credential for authenticated scans and this leads to the posted error? You have listed an error log from the scanner which isn’t related to python-gvm. python-gvm talks to openvasmd/gvmd. See

So maybe you have discovered an issue in a nasl script or openvassd directly. But most likely it is not related to python-gvm.

3

If the issue is about the following two below then its a scanner as well as NASL related topic:

This just means that the libssh library linked against the scanner doesn’t support this algorithm yet. The algorithm probably will be supported by libssh and the message is then gone.

This was indeed an issue in that specific VT and should be fixed in one of the next feed updates.

4

@bricks this bug as far as I can see does not look like it is linked to the Python library. I was just describing that I was using it but I guess if I communicated via the GMP protocol passing an xml element with login but no password defined then that would cause the scanner to throw those errors.

@cfi I was not trying any special algorithm, I wanted to provide a username and password to create a ssh account, but in this instance no password was provided (no password element in XML) and that then caused that error you can see in my previous thread which then leads to the error infinitely being thrown and causing a large number of core files to be created on my server. I would expect this to inform you of the error once rather than being stuck in a loop.

Thanks

5

As previously explained the log entries posted in the first post are not related to any memory leak or any credentials created by an API. Both are also not causing any core files to be created. The first message is just a little bit too verbose logging from the scanner where the second one was a bug in that specific single VT.

In addition those are also not thrown infinitely but only logged multiple times because e.g. the bug in the mentioned VT has stacked up for each call of the VT and for each scanned host (similar with the SSH log entry).

Maybe we should strip/remove this information from this thread so the focus is kept on the “core files” topic?

1 Like