oss-security - [no-cve] Nim - Insecure SSL/TLS Defaults, MitM, and nimble shell command injection

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [day] [month] [year] [list]

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.
```

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.