[SECURITY/CVE/CRITICAL] Meshcentral is injected during docker build run

[iocron]

What happened?

The command devbox generate dockerfile generates a docker file that pulls dangerous/malicious dependencies (meshcentral 1.1.6 package, ~500MB) during the docker build process (e.g. docker build -t devbox-empty-test2 .).

How to reproduce:

devbox init
devbox add vim # added random package, because devbox throws a error if devbox.lock does not exist yet..
devbox rm vim
devbox generate dockerfile -f
docker build -t devbox-empty-test2 .

Looking at the Dockerfile (cat Dockerfile) reveals:

FROM jetpackio/devbox:latest

# Installing your devbox project
WORKDIR /code
USER root:root
RUN mkdir -p /code && chown ${DEVBOX_USER}:${DEVBOX_USER} /code
USER ${DEVBOX_USER}:${DEVBOX_USER}
COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} devbox.json devbox.json
COPY --chown=${DEVBOX_USER}:${DEVBOX_USER} devbox.lock devbox.lock

RUN devbox run -- echo "Installed Packages."

CMD ["devbox", "shell"]

During the execution of RUN /bin/sh -c devbox run -- echo "Installed Packages." # buildkit the dangerous dependencies are pulled through the meshcentral 1.1.6 package. This is very disturbing, also because the package does not make any sense to exist in the first place on a empty Project.

Inspect the generated docker image by using docker-desktop (or a suitable vuln/dep scanning tool):

Just the meshcentral 1.1.6 package alone has 4 CVEs. 3 with high severity and 1 with critical severity. The CVEs are:
CVE-2023-51837
CVE-2024-26135⁠
CVE-2023-51842
CVE-2023-51838

Steps to reproduce

devbox init
devbox add vim # just added random package, because devbox throws a error that devbox.lock does not exist yet..
devbox rm vim
devbox generate dockerfile -f
docker build -t devbox-empty-test2 .

Command

No response

devbox.json

{
  "$schema":  "https://raw.githubusercontent.com/jetify-com/devbox/0.13.7/.schema/devbox.schema.json",
  "packages": [],
  "shell": {
    "init_hook": [
      "echo 'Welcome to devbox!' > /dev/null"
    ],
    "scripts": {
      "test": [
        "echo \"Error: no test specified\" && exit 1"
      ]
    }
  }
}

Devbox version

0.13.7

Nix version

nix (Nix) 2.24.7

What system does this bug occur on?

macOS (Apple Silicon)

Debug logs

macOS 14.6.1 (Apple M1 Pro)

[ipince]

Thanks for the report. We're looking into it.

[mohsenari]

@iocron thanks for reporting this issue, I looked into it quite in detail. The CVE is correct but Meshcentral is not injected at all. In fact, there is no Meshcentral binary in the container. I searched for it in the entire filesystem in a built container.
There are 2 places where meshcentral exists:

devbox@f85313a7724c:/code$ find / -type f -name "*meshcentral*" 2>/dev/null

/nix/store/5kli0hmba13hczv8gni1gvzi4ir8w21b-nixpkgs/nixpkgs-25.05pre720687.5a48e3c2e435/nixos/modules/services/admin/meshcentral.nix

/nix/store/j0jlb33bm31w347w43051hbffgh616jr-source/nixos/modules/services/admin/meshcentral.nix

The first path is part of the nixpkgs package itself that contains a few .nix files as services. meshcentral.nix is there to allow remote desktop capability to nixOS. The second file is the source for those services.

That said, if you add RUN nix-garbage-collect -d & RUN nix-store --optimise after devbox run, it will remove these files and the scanner tool won't flag them as critical.
These 2 lines, remove unused packages and files in nix store and deduplicate installed packages.

RUN devbox run -- echo "Installed Packages."

RUN nix-collect-garbage -d
RUN nix-store --optimise

[iocron]

@mohsenari @ipince You're welcome, happy to help.

@mohsenari Thats incorrect. There are multiple places, and the binary does exist, let me explain it below shortly (due to restricted time I only checked a small portion):

1. At first sight there are artifacts of a meshcentral node/yarn installation and obfuscation at multiple places, not just a binary (sudo grep -rin meshcentral /nix/store can be one of multiple starting points)
2. /nix/store/2ikz1s663gfg2sxg1yrv4wzjn908axg2-nixexprs.tar.xz (filename/hash might slightly differ) has the binary meshcentral (and some other dependencies and IaC tools like pgadmin, procs, pulumi, google cloud sdk, etc.)
3. there are some obfuscations going on anyway (finding all indices and unraveling/resolving the obfuscation might take a long time). Also there might be some hooking going on (e.g. some proc or static trigger unpacks and uses the file only during a specific interaction)
4. Meshcentral is not part of any nix/nixos default, also bloats the image massively, my question is why is it there in the first place?
5. "meshcentral.nix is there to allow remote desktop capability to nixOS" => Why would anyone ever want to allow a rdp tool/service like meshcentral inside a default docker image?
6. Due to all points mentioned, I do highly recommend to remove the injected packages from the default docker generation. A garbage collection like nix-collect-garbage -d && nix-store --optimise does not solve the problem / root cause

[gcurtis]

@iocron I went through and looked at the Docker Desktop results, and this seem like a false-positive that's detecting the package.json file for meshcentral. The exact location I got was /nix/store/j0jlb33bm31w347w43051hbffgh616jr-source/pkgs/tools/admin/meshcentral/package.json.

nixpkgs sometimes includes files like this so it can auto-generate parts of the build process for packages. In this case, it uses the package.json to download/hash dependencies of meshcentral and update the package.

To be clear, none of this is actually happening and meshcentral isn't actually being built unless you install meshcentral with Devbox or Nix. It's just in the container because Nix packages are all defined in the same git repo.

I looked in the paths you mentioned (including in /nix/store/2ikz1s663gfg2sxg1yrv4wzjn908axg2-nixexprs.tar.xz) and couldn't find an actual binary anywhere. If there are specific paths you think we should take a look at, let us know.