Nix 2.24.8 released fixing builtin:fetchurl credentials leak, severity 5.9 (moderate)

Announcements Security
1

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.

source: https://x.com/DeterminateSys/status/1839145876486242659

Here’s the contents of the related security advisor: Credential leak when credentials are used with `<nix/fetchurl.nix>` · Advisory · NixOS/nix · GitHub

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.

9 Likes
Announcing Determinate Nix
2

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.

4 Likes
3

Im confused. The quote you link says builtins.fetchurl is not affected by the change. Typo?

1 Like
4

Here is the Nix advisory: Credential leak when credentials are used with `<nix/fetchurl.nix>` · Advisory · NixOS/nix · GitHub

This is fixed in Nix 2.24.8 (and we’ll also do some backport releases for older versions.)

The quote you link says builtins.fetchurl is not affected by the change.

Indeed builtins.fetchurl is not affected.

2 Likes
5

this says it was posted 4 minutes ago, forgot to publish or intentional?

Anyways, I’ll add the link to the top post, thanks :slight_smile:

1 Like
6

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.

1 Like
Announcing Determinate Nix
7

So the DetSys tweet was an accidental leak? Might be worth considering in maintainers: add checklist for security releases by fricklerhandwerk · Pull Request #11400 · NixOS/nix · GitHub

1 Like
8

So the DetSys tweet was an accidental leak?

Not quite, builtin:fetchurl: Enable TLS verification by edolstra · Pull Request #11585 · NixOS/nix · GitHub had been publicly merged and Nix 2.24.8 has been released at that point.

9

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.

10 Likes
10

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.

8 Likes
11

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.

12

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!

16 Likes
13

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.

2 Likes
14

tbf the manual explicitly says this:

https://nixos.org/manual/nixpkgs/stable/#sec-pkgs-fetchers-secure-hashes

https:// URLs are secure when using the fake hash method only 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.

i.e. you must use one of the following

  • ""
  • lib.fakeHash
  • lib.fakeSha256
  • lib.fakeSha512
1 Like
15

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. :slightly_smiling_face:

2 Likes
Announcing Determinate Nix
16

Fair. It’s a good thing that this is in the manual, but I still strongly believe that’s not good enough.

People have expectations when they read https somewhere, violating those expectations is still bad, even if your manual says that what you do.

Users of any project, Nix included, can only keep track of a limited number of quirks and issues like that.

3 Likes
17

I 100% agree, I just wanted to mention that it is documented (which is arguably even worse since it’s advertising the vuln without fixing it?)

1 Like