DetSys seems to have made a security release to NixCpp.
The primary risk is leaking of netrc credentials through a crafted derivation plus an attacker-in-the-middle. Users of the experimental feature impure-derivations are at greater risk.
FlakeHub Cache users and users of impure derivations should upgrade as soon as possible.
Credential leak when credentials are used with <nix/fetchurl.nix>
Impact
<nix/fetchurl.nix> historically did not verify TLS certificates on HTTPS connections. This could lead to connection details such as full URLs or credentials leaking in case of a man-in-the-middle (MITM) attack.
You may be affected by the risk of leaking credentials if you have a netrc file for authentication, or rely on derivations with impureEnvVars set to use credentials from the environment.
In addition, the commonplace trust-on-first-use (TOFU) technique of updating dependencies by specifying an invalid hash and obtaining it from a remote store was also vulnerable to a MITM injecting arbitrary store objects. This also applied to the impure derivations experimental feature.
Note that this may also happen when using Nixpkgs fetchers to obtain new hashes when not using the fake hash method, although that mechanism is not implemented in Nix itself but rather in Nixpkgs using a fixed-output derivation.
The behavior was introduced in 5db358d to make it consistent with the Nixpkgs pkgs.fetchurl and to make <nix/fetchurl.nix> work in the derivation builder sandbox, which back then did not have access to the CA bundles by default. Nowadays, CA bundles are bind-mounted on Linux.
Patches
This issue has been fixed on Nix master and in Nix 2.24.8.
Workarounds
Implement (authenticated) fetching with pkgs.fetchurl from Nixpkgs, using impureEnvVars and curlOpts as needed.
I found this in commit logs from yesterday, which may make the impact more clear than the tweet:
---
synopsis: "`<nix/fetchurl.nix>` uses TLS verification"
prs: [11585]
---
Previously `<nix/fetchurl.nix>` did not do TLS verification. This was because
the Nix sandbox in the past did not have access to TLS certificates, and Nix
checks the hash of the fetched file anyway. However, this can expose
authentication data from `netrc` and URLs to man-in-the-middle attackers. In
addition, Nix now in some cases (such as when using impure derivations) does
*not* check the hash. Therefore we have now enabled TLS verification. This
means that downloads by `<nix/fetchurl.nix>` will now fail if you're fetching
from a HTTPS server that does not have a valid certificate.
`<nix/fetchurl.nix>` is also known as the builtin derivation builder
`builtin:fetchurl`. It's not to be confused with the evaluation-time function
`builtins.fetchurl`, which was not affected by this issue.
Seems to also include a breaking change for https urls for builtins:fetchurl against invalid certs.
We weren’t done with with the text in yesterday’s meeting, and the backport releases aren’t yet out, but now that it’s out we decided to post it as is.
It may be best to coordinate these sorts of announcements. Folks are excited for a new version, but may be confused when a secondary party announces a release without there being any mention of it on official spaces.
Right but the advisor would have been released when? Clearly it wasn’t blocked by backports then, and I’m pretty sure determinate systems twitter isn’t the channel where most of us are looking for security updates?
Can we all just agree that this should have been posted in official channels, I really don’t see why there should be an information asymmetry that prefers determinate systems twitter over the place where security disclosures are normally made.
It’s kinda silly that I have to make a post here just to get stuff like that out the door.
Well yes, and to me this is a leak, I don’t know when this would have actually been publicly disclosed in official channels, and in that time period, someone that follows determinate systems could potentially have exploited this issue.
Sure, but without the advisory, most affected people would’ve felt less urgency to update to a just-released Nix version.
The only people who would’ve been “in the know” between Tweet and advisory are:
those who instantly check the release notes of every Nix release (and it’s not even clear where to find them)
those who follow DetSys on Twitter
It seems unfair that those who subscribe to security advisories on the Nix repo should be at a disadvantage here. And I’m sure it won’t inspire confidence in the professionalism of the team.
I think this is a pretty clear cut issue, @edolstra – don’t announce security fixes in the DetSys Twitter first!
Not sure there are still other fetchers which do not do verify TLS certificates on HTTPS connections in nixpkgs or other places. If there are any, I really think they should be changed as well.
People, including myself, assume there is transport security when they use some function to fetch an https URL and that assumption should not be violated (without some well-named extra argument to the fetcher). I had no idea lib.fakeSha256 was load-bearing for security, and I don’t think it should be.
https:// URLs are secure when using the fake hash methodonly if you use one of the listed fake hashes. If you use any other hash, the download will be exposed to MITM attacks even if you use HTTPS URLs.
Can we resolve this with the Nix community values? Security issues by definition need a coordinated fix to benefit everyone, which conflicts with (emphasis mine, from the section I linked):
We are a synthesis of varied but overlapping communities. We rely on distributed approaches: asynchronous communication, clear ownership, deep-dive taskforces, and local decisionmaking.
If ownership is unclear, it tends to make issues caused by asynchronous communication and different groups making different decisions worse. It’s a problem in engineering orgs as old as time, too, so it has a fix that’s equally tried and true: if there’s no agreement about where to publish the vuln first, then you just make something up and roll with it if everyone agrees. Publishing the Github vuln announcement seems like a solid “it goes here first” step.
