CVE-2018-6517 in chloride
Summary
by MITRE
Prior to version 0.3.0, chloride's use of net-ssh resulted in host fingerprints for previously unknown hosts getting added to the user's known_hosts file without confirmation. In version 0.3.0 this is updated so that the user's known_hosts file is not updated by chloride.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 05/18/2020
The vulnerability described in CVE-2018-6517 affects chloride version 0.3.0 and earlier, representing a significant security flaw in SSH host key verification mechanisms. This issue stems from chloride's integration with the net-ssh library, which historically failed to implement proper host key confirmation procedures when establishing new SSH connections. The flaw creates a dangerous situation where unverified host fingerprints are automatically appended to users' known_hosts files without any explicit consent or validation from the user. This behavior fundamentally undermines the core security principle of SSH host key verification, which relies on explicit user confirmation to establish trust relationships with remote servers.
The technical nature of this vulnerability aligns with CWE-295, which addresses improper certificate validation and host key verification issues in network communications. The flaw operates at the protocol level where chloride's SSH implementation bypasses standard security checks that should occur during initial host key establishment. When chloride encounters a new SSH host, it automatically accepts and stores the host's fingerprint in the user's known_hosts file, effectively creating a trust relationship without proper verification. This automatic behavior exposes users to potential man-in-the-middle attacks where malicious actors could potentially intercept connections by presenting forged host keys that would be automatically accepted and stored.
From an operational perspective, this vulnerability creates a persistent security risk that can have far-reaching consequences for users and organizations. The automatic addition of host fingerprints to known_hosts files means that any compromised or malicious SSH server could establish trust relationships that persist indefinitely until manually removed by the user. This represents a critical failure in the SSH security model where the user's explicit consent is bypassed, potentially allowing attackers to gain access to systems through previously unknown but trusted hosts. The vulnerability essentially provides a backdoor mechanism for attackers to establish persistent trust relationships with target systems without requiring additional user interaction or awareness.
The remediation implemented in chloride version 0.3.0 addresses this issue by modifying the host key verification process to require explicit user confirmation before updating the known_hosts file. This change aligns with established security best practices and follows the principle of least privilege in network communications. The updated implementation ensures that users must actively confirm host fingerprints before trust relationships are established, preventing automatic trust establishment that could be exploited by malicious actors. This mitigation directly addresses the ATT&CK technique T1566, which involves social engineering attacks through credential access, by ensuring that users maintain control over their SSH host verification processes.
Security professionals should note that this vulnerability demonstrates the importance of proper host key verification in SSH implementations and highlights the risks associated with automated trust establishment mechanisms. Organizations using chloride or similar tools should ensure they are running version 0.3.0 or later to prevent potential exploitation of this flaw. The vulnerability also underscores the need for regular security audits of third-party libraries and their integration points, as the net-ssh dependency's behavior directly influenced the overall security posture of chloride. This case illustrates how seemingly minor implementation details in cryptographic libraries can have significant security implications when not properly validated against established security standards and user consent requirements.