oss-sec mailing list archives

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


From: Martin Ortner <martin.ortner () consensys net>
Date: Fri, 5 Feb 2021 10:42:28 +0100

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




Current thread: