Date: Fri, 5 Feb 2021 10:42:28 +0100 From: Martin Ortner <martin.ortner@...sensys.net> To: oss-security@...ts.openwall.com Subject: [no-cve] Nim - Insecure SSL/TLS Defaults, MitM, and nimble shell command injection title: "Nim - Insecure SSL/TLS Defaults, MitM, and nimble shell command injection" date: 2021-02-04T14:13:23+01:00 cve: vendor: nim-lang vendorUrl: https://nim-lang.org/ authors: tintinweb affectedVersions: [ "<= 1.2.6", "nimble <=v0.12.0"] vulnClass: CWE-295, CWE-78, CWE-348 Vulnerability Note: https://consensys.net/diligence/vulnerabilities/nim-insecure-ssl-tls-defaults-remote-code-execution/ Vulnerability Note: https://github.com/tintinweb/pub/ Group: https://consensys.net/diligence/research/ # Vulnerability Note ## Summary We found a couple of critical security issues in the defaults for one of the standard-lib components that allows peer-impersonation (MitM) on secure transports. This also affects the languages package manager. Additionally, the package manager is vulnerable to shell command injection when fetching remote repositories before installing packages: * 2.1 - `httpClient` does no validate peer certificates by default (appears to be fixed in 1.4.x) * 2.2 - the package manager `nimble` relies on the insecure `httpClient` defaults (unfixed; latest 0.12.0 has not been re-compiled with a fixed nim-c) * 2.3 - `nimble` falls back to insecure transports if `https` is blocked (unfixed) * 2.4 - `nimble` shell command injection when fetching a package for installation (unfixed) **TLDR;** The Nim (`at least <=1.2.6`) `httpClient` default SSL/TLS configuration does not enforce peer certificate verification by default. Non-secure settings should not be the default as this might unexpectedly expose other projects to security risks. If you're using `nimble <= 0.12.0` anyone can block your TLS session and it will fall back to an insecure transport. Because of the insecure `httpClient` defaults, one can also just intercept your TLS session as the peer verification is too lax. Additionally, nimble appears to be vulnerable to a direct shell command injection when installing a package (but one can as well just provide a malicious package). ## Details see https://consensys.net/diligence/vulnerabilities/nim-insecure-ssl-tls-defaults-remote-code-execution/ ## Proof of Concept see https://consensys.net/diligence/vulnerabilities/nim-insecure-ssl-tls-defaults-remote-code-execution/ ### Timeline ``` JUL/09/2020 - contact nim developers @telegram; provided details, PoC FEB/04/2021 - deadline met. full disclosure. ```
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.