Penetration Test Report (Cure53): pentest report libssh

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Pentest-Report libssh C Library 09.2019
Cure53, Dr.-Ing. M. Heiderich, MSc. N. Krein, Prof. N. Kobeissi, MSc. D. Weißer,
BSc. J. Hector, B. Walny
Index
Introduction
Scope
Identified Vulnerabilities
SSH-01-003 Client: Missing NULL check leads to crash in erroneous state (Low)
SSH-01-004 SCP: Unsanitized location leads to command execution (Critical)
SSH-01-006 General: Various unchecked Null-derefs cause DOS (Low)
SSH-01-007 PKI Gcrypt: Potential UAF/double free with RSA pubkeys (Medium)
SSH-01-010 SSH: Deprecated hash function in fingerprinting (Low)
SSH-01-011 SSH: Lack of point validation on X25519 and Ed25519 (Medium)
SSH-01-013 Conf-Parsing: Recursive wildcards in hostnames lead to DOS (Low)
SSH-01-014 Conf-Parsing: Integer underflow leads to OOB array access (Low)
Miscellaneous Issues
SSH-01-001 State Machine: Initial machine states should be set explicitly (Info)
SSH-01-002 Kex: Differently bound macros used to iterate same array (Info)
SSH-01-005 Code-Quality: Integer sign confusion during assignments (Low)
SSH-01-008 SCP: Protocol Injection via unescaped File Names (Low)
SSH-01-009 SSH: RFC4255 not Implemented (Info)
SSH-01-012 PKI: Information leak via uninitialized stack buffer (Low)
Conclusions
Cure53, Berlin · 10/11/19 1/18
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Introduction
“libssh is a multiplatform C library implementing the SSHv2 protocol on client and server
side. With libssh, you can remotely execute programs, transfer files, use a secure and
transparent tunnel, manage public keys and much more ...”
From https://www.libssh.org/
This report documents the findings of a security assessment targeting the libssh
software. Carried out by Cure53 in September and October 2019, this project entailed
both a penetration test and a source code audit. The focus was placed on the libssh
software, which is available as open source and currently shipped in version v0.9.
Fourteen security-relevant findings, including one marked as “Critical” in terms of impact,
have been spotted by Cure53 on the scope.
It needs to be clarified that this assessment was generously funded by Mozilla. The
budget stemmed from the framework of the Mozilla Open Source Support (MOSS)
initiative, specifically the Secure Open Source funding track. Cure53 was introduced to
the libssh team and its maintainers by Mozilla. From there, the assessment was planned
collaboratively. Resources-wise, Cure53 approached this assessment of libssh with a
team of six senior testers. The total time invested into the completion of this examination
came up to thirty-two person-days. All work - spanning core tests, documentation,
reporting and write-up - was done in late September and early October 2019.
In order to fulfill the objectives of this assessment in an organized fashion, three work
packages (WPs) have been created. WP1 encompassed the libssh source code audit,
during which Cure53 focused on investigating the available sources with the overarching
goal of identifying vulnerable sections. Code-assisted penetration testing, reliant on the
use of the reference server and client implementations, as well as local setups created
by the Cure53, has been performed during WP2. Finally, WP3 centered on libssh
protocol Fuzzing and formal verification using AFL. The latter partly happened in parallel
to the test and was also accompanied by formal verification with the ProVerif tool. To
clarify the goal, it should be stated that Cure53 sought to find out whether the protocol
handshakes are as secure as they are supposed to be.
To prepare for the test, several briefing meetings were held. In addition, the libssh team
supplied Cure53 with a scope document with instructions pertinent to the test setup,
interesting areas and general info about the expectations regarding the test and
assessment’s results. Consequently, the project started on time and progressed
efficiently. Communications during the assessment took place in an IRC channel on
Freenode, which was made available by the maintainers of the libssh project. Cure53
Cure53, Berlin · 10/11/19 2/18
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
furnished regular status updates and shared relevant findings as they emerged rather
than upon waiting for the final completion of this report.
Among the spotted fourteen findings, eight were classified as security vulnerabilities and
six were noted as general weaknesses with lower exploitation potential. While one item
received a “Critical” marker, it must be noted that its exploitability does not extend to
every piece of software that utilizes the libssh API. Nevertheless, it was demonstrated
that popular software such as cURL is prone to the proposed attack scenario, thus
causing the vulnerability to be marked as higher than originally proposed. Quite
impressively, all other problems had only “Medium” and lower grades, indicating a good
overall outcome of this Cure53 assessment of the libssh software.
In the following sections, the report will first briefly reiterate the scope and three specific
WPs. It then moves on to dedicated, chronologically discussed tickets, which shed light
on the discoveries one-by-one. Alongside technical aspects like PoCs, Cure53 furnishes
mitigation advice for improving libssh going forward. The report closes with a broader
conclusion in which Cure53 summarizes this autumn 2019 project and issues a verdict
about the tested scope. Further, detailed recommendations and notes on the security
and privacy posture of the libssh software are supplied in the final section of this
document.
Scope
• libssh server- and client-side code
◦ WP1: libssh source code audits
▪ https://www.libssh.org/files/0.9 /
◦ WP2: libssh penetration tests, code-assisted (using reference server & client)
◦ WP3: libssh protocol fuzzing & formal verification (using AFL & ProVerif)
◦ A detailed scope document was made available to Cure53 by the libssh maintainers
◦ Build instructions were provided
Cure53, Berlin · 10/11/19 3/18
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Identified Vulnerabilities
The following sections list both vulnerabilities and implementation issues spotted during
the testing period. Note that findings are listed in chronological order rather than by their
degree of severity and impact. The aforementioned severity rank is simply given in
brackets following the title heading for each vulnerability. Each vulnerability is
additionally given a unique identifier (e.g. SSH-01-001) for the purpose of facilitating any
future follow-up correspondence.
SSH-01-003 Client: Missing NULL check leads to crash in erroneous state (Low)
It was discovered that a crypto function does not properly check for a null pointer,
allowing for a malicious server to cause a libssh-based client application to crash. In
certain scenarios, this can lead to information leakage, for instance when core dumps
are written and made available to the attacker.
When an SSH client establishes a connection, the server sends back its public key. In
case this key cannot be parsed correctly, the libssh client cannot setup the required
crypto parameters. As such, it causes the ssh_connect() function to return an error. If the
ssh_disconnect() function is called in this erroneous state, the client crashes while
encrypting the disconnect-message. This is because the required data structs have not
been initialized. The following code snippet shows where the crash occurs. It can be
seen that out_cipher is not initialized, causing a Null Pointer Dereference upon access to
out_cipher->blocksized being attempted.
Affected File:
libssh-0.9.0/src/packet.c
Affected Code:
static int packet_send2(ssh_session session)
{
[...]
crypto = ssh_packet_get_current_crypto(session, SSH_DIRECTION_OUT);
if (