# Protect Nix codebases against Trojan Source (CVE-2021-42574)

**URL:** https://discourse.nixos.org/t/protect-nix-codebases-against-trojan-source-cve-2021-42574/16316
**Category:** Development
**Created:** [November 29, 2021, 7:53am UTC](https://discourse.nixos.org/t/protect-nix-codebases-against-trojan-source-cve-2021-42574/16316 "2021-11-29T07:53:29Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![shamrocklee](https://discourse.nixos.org/user_avatar/discourse.nixos.org/shamrocklee/32/28815_2.png) [@shamrocklee](https://discourse.nixos.org/u/shamrocklee)
#### Post date: [November 29, 2021, 7:53am UTC](https://discourse.nixos.org/t/protect-nix-codebases-against-trojan-source-cve-2021-42574/16316/1 "2021-11-29T07:53:29Z")

</div>

A cross-language source-level vulnerability known as Trojan Source (CVE-2021-42574) was made public on November 1st, 2021. It is based on non-closed Unicode explicit-directional-changing (RTL) control characters that allows the attacker to arbitrarily change the order of character sections and influence characters outside a comment or a string.

> **[GitHub - nickboucher/trojan-source: Trojan Source: Invisible Vulnerabilities](https://github.com/nickboucher/trojan-source)**
>
> Trojan Source: Invisible Vulnerabilities. Contribute to nickboucher/trojan-source development by creating an account on GitHub.

The Nix toolchain seems to be unaware of such kind of vulnerabilities. GitHub has added a warning to files with non-closed RTL characters in the source tree, but it would be better if the problem can also be found by the Nix linter, formatter and Nix-CI (OfBorg).

I have opened an issue in the nix-community/nixpkgs-fmt project which includes the Python scripts to generate poisoned Nix expressions as a proof-of-concept implementation of the vulnerability. Here’s how it looks like:

```plaintext

{ lib, hello }:
hello.overrideAttrs (oldAttrs:
  let
    scrSecure = builtins.trace "Using the secure source" oldAttrs.src;
  in {
    pname = oldAttrs.pname + "-secure";
    /*Replace the source with a secure one<U+202E><U+2066>src = srcSecure;<U+2069><U+2066>*/
})

```

[https://github.com/nix-community/nixpkgs-fmt/issues/276](https://github.com/nix-community/nixpkgs-fmt/issues/276)

---

<div class="post-metadata">

### Author: ![earvstedt](https://discourse.nixos.org/user_avatar/discourse.nixos.org/earvstedt/32/310_2.png) [@earvstedt](https://discourse.nixos.org/u/earvstedt)
#### Post date: [November 29, 2021, 1:51pm UTC](https://discourse.nixos.org/t/protect-nix-codebases-against-trojan-source-cve-2021-42574/16316/2 "2021-11-29T13:51:14Z")

</div>

Related:  
[https://research.swtch.com/trojan](https://research.swtch.com/trojan)  
[https://github.com/ziglang/zig/issues/10074](https://github.com/ziglang/zig/issues/10074)

Summary: This has to be addressed in editors/code review tools, not at lower levels of the tooling stack.

---

<div class="post-metadata">

### Author: ![raboof](https://discourse.nixos.org/user_avatar/discourse.nixos.org/raboof/32/1681_2.png) [@raboof](https://discourse.nixos.org/u/raboof)
#### Post date: [November 29, 2021, 4:01pm UTC](https://discourse.nixos.org/t/protect-nix-codebases-against-trojan-source-cve-2021-42574/16316/3 "2021-11-29T16:01:55Z")

</div>

> [@earvstedt](#):
>
> This has to be addressed in editors/code review tools

Yes

> [@earvstedt](#):
>
> It does not at lower levels of the tooling stack.

Though why not both? The linter/formatter/CI seem like sensible places to (also) validate this.

---

<div class="post-metadata">

### Author: ![shamrocklee](https://discourse.nixos.org/user_avatar/discourse.nixos.org/shamrocklee/32/28815_2.png) [@shamrocklee](https://discourse.nixos.org/u/shamrocklee)
#### Post date: [November 30, 2021, 2:32pm UTC](https://discourse.nixos.org/t/protect-nix-codebases-against-trojan-source-cve-2021-42574/16316/4 "2021-11-30T14:32:08Z")

</div>

> [@earvstedt](#):
>
> This has to be addressed in editors/code review tools

Editors often rely on linters/formatters to highlight the code correctly, to format the code, and to show diagnostic messages. A general editor such as VSCode doesn’t understand the string block/comment block itself, and requires language-specific plugins to do the work. The plugins then turns to the linters and formatters.

I don’t know much about the review tools, but similar situations might occur IMHO.

Update: I’m unable to come out with an example in which the closing RTL characters fall into another string/comment block in the same line, nor is there one in Boucher and Anderson’s paper. But that’s still imaginable somehow.