Environment variables still accessible through /proc

published 2023-12-01 2y ago modified 2023-12-01 2y ago

cvss: 4.0; version 3.1, GitHub
cisa kev: Not listed; not in CISA's catalog
epss: —; no score, EPSS covers CVEs only
public exploits: 0; none known

### Impact

Environment variables can be read from procfs unless a new process is started.

### PoC

``` use birdcage::{Birdcage, Sandbox}; use std::{env, fs};

fn main() { Birdcage::new().lock().unwrap();

assert_eq!(env::var_os("SECRET"), None);

let environ = fs::read_to_string("/proc/self/environ").unwrap(); assert!(!environ.contains("SECRET"), "ENVIRON CONTAINS SECRET:\n{environ}"); } ```

``` $ SECRET=test cargo run thread 'main' panicked at src/main.rs:10:5: ENVIRON CONTAINS SECRET: [truncated] ```

### Possible Solutions

The simplest solution would be relying on the ptrace isolation and **always** spawning a new process by changing birdcage's API to create a new command. With an additional PID namespace the guarantees could be even further reinforced.

Patch / fix

fixed in 1

crates.io birdcage 0.7.0

Is GHSA-wj7f-468m-6mv8 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

CVSS scores

assigned by	version	score	vector
GitHub	3.1	4.0	CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Affected packages

ecosystem	package	affected	fixed in
crates.io	birdcage	<0.7.0	0.7.0

Classification

Weakness

CWE-200 Exposure of Sensitive Information to an Unauthorized Actor

References

Sources

GitHub Advisory GHSA-wj7f-468m-6mv8

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.