update: runc

[t-lo]

Name: app-containers/runc
CVEs: CVE-2024-21626, GHSA-xr7r-f8xq-vfvv
CVSSs: 8.6 (high)
Action Needed: Update to >= 1.1.12

Summary: In runc v1.1.11 and earlier, due to certain leaked file descriptors, an attacker can gain access to the host filesystem by causing a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, or by tricking a user to run a malicious image and allow a container process to gain access to the host filesystem through runc run. The attacks can also be adapted to overwrite semi-arbitrary host binaries, allowing for complete container escapes. Note that when using higher-level runtimes (such as Docker or Kubernetes), this vulnerability can be exploited by running a malicious container image without additional configuration or by passing specific workdir options when starting a container. The vulnerability can also be exploited from within Dockerfiles in the case of Docker.

refmap.gentoo: TBD

[t-lo]

The latest sysext bakery release ships a Docker sysext that includes a fix (docker 24.0.9): https://github.com/flatcar/sysext-bakery/releases/tag/latest. Using the sysext can mitigate the issue until we publish new OS releases later in February.
Check out the readme in the sysext bakery https://github.com/flatcar/sysext-bakery as well as our documentation on sysexts https://www.flatcar.org/docs/latest/provisioning/sysext/ for more information

[tgelter]

EDIT: This can be ignored. I found that our code was blacklisting the squashfs kernel module, which was leading to the failure. Thanks!

---

The latest sysext bakery release ships a Docker sysext that includes a fix (docker 24.0.9): https://github.com/flatcar/sysext-bakery/releases/tag/latest. Using the sysext can mitigate the issue until we publish new OS releases later in February. Check out the readme in the sysext bakery https://github.com/flatcar/sysext-bakery as well as our documentation on sysexts https://www.flatcar.org/docs/latest/provisioning/sysext/ for more information

Hi Flatcar team. I've been trying to get this working most of today without luck. I'm finding that there aren't many sources online to help me troubleshoot this, so please forgive my muddying of this issue but perhaps it can help someone else trying desperately to work around this CVE.

I have adjusted the Ignition data our system provisioning system uses and have the file laying down to what I believe is the correct place, but I can't get any further than that before I hit a blocking issue:

# systemd-sysext list   
NAME                 TYPE PATH                                     TIME                       
docker-24.0.9-x86-64 raw  /etc/extensions/docker-24.0.9-x86-64.raw Thu 2024-02-01 23:17:02 UTC

# systemd-sysext refresh
Failed to read metadata for image docker-24.0.9-x86-64: No such device

I found a message from Lennart Poettering responding to a question about this symptom someone else saw:

The image must come with verity + signature, we'll not allow unsigned
extensions by default. (you could relax the image policy if you want,
or disable it but I'd advise you not to. The env var
SYSTEMD_DISSECT_VERITY_SIGNATURE=0 tells sysext to not validate images)

Some debug info:

# sudo SYSTEMD_LOG_LEVEL=debug systemd-sysext refresh
Opened '/etc/extensions/docker-24.0.9-x86-64.raw' in O_RDONLY access mode, with O_DIRECT enabled.
Successfully acquired /dev/loop3, devno=7:3, nr=3, diskseq=8
Opened /dev/loop3 (fd=5, whole_block_devnum=7:3, diskseq=8).
Successfully forked off '(sd-dissect)' as PID 3252.
Mounting /proc/self/fd/5 (squashfs) on /tmp/dissect-UitYeT (MS_RDONLY|MS_NODEV "")...
Failed to mount /proc/self/fd/5 (type squashfs) on /tmp/dissect-UitYeT (MS_RDONLY|MS_NODEV ""): No such device
Failed to mount dissected image: No such device
Failed to read /etc/hostname of image: No such file or directory
/etc/machine-id file of image is empty.
Failed to read has-init-system boolean: Input/output error
(sd-dissect) failed with exit status 1.

Note that we are still on Flatcar v3510.2.5 and our provisioning system uses Ignition v2.3.0. This is what was added to the generated JSON which was adapted somewhat from the example given in the documentation which was lined by @t-lo above:

❯ git --no-pager diff src/resources/ignition/output/ignition-datacenter-worker.json
diff --git a/src/resources/ignition/output/ignition-datacenter-worker.json b/src/resources/ignition/output/ignition-datacenter-worker.json
index 047e03aba..08ddb31d8 100644
--- a/src/resources/ignition/output/ignition-datacenter-worker.json
+++ b/src/resources/ignition/output/ignition-datacenter-worker.json
@@ -670,6 +670,26 @@
         },
         "mode": 420
       },
+      {
+        "filesystem": "root",
+        "path": "/etc/extensions/docker-24.0.9-x86-64.raw",
+        "contents": {
+          "source": "https://github.com/flatcar/sysext-bakery/releases/download/latest/docker-24.0.9-x86-64.raw",
+          "verification": {
+            "hash": "sha512-067816da3943bd350e97d9dcbb6bedc9fadf742442558033462dec50a9de0d65f6df8cceb68ef73ef662c3fa6d1878dad5bd5373a55abf7150610b152b336db4"
+          }
+        },
+        "mode": 420
+      },
+      {
+        "filesystem": "root",
+        "path": "/etc/systemd/system-generators/torcx-generator",
+        "contents": {
+          "source": "data:,",
+          "verification": {}
+        },
+        "mode": 420
+      },
       {
         "filesystem": "root",
         "path": "/<redacted>/download-certificates.sh",
@@ -814,6 +834,20 @@
         },
         "mode": 493
       }
+    ],
+    "links": [
+      {
+        "filesystem": "root",
+        "overwrite": true,
+        "path": "/etc/extensions/docker-flatcar.raw",
+        "target": "/dev/null"
+      },
+      {
+        "filesystem": "root",
+        "overwrite": true,
+        "path": "/etc/extensions/containerd-flatcar.raw",
+        "target": "/dev/null"
+      }
     ]
   },
   "systemd": {

I've compared the SHA for the downloaded docker-24.0.9-x86-64.raw file to the source from sysext-bakery and confirmed they match.

I don't find evidence that the cause of the issue I'm observing is the "verity + signature" issue but instead expect it's an issue with my configuration but can't seem to put a finger on it.

Any tips are appreciated!

---

EDIT: This can be ignored. I found that our code was blacklisting the squashfs kernel module, which was leading to the failure. Thanks!

[jbrockopp]

EDIT: The issue was resolved by renaming docker-24.0.9-x86-64.raw to docker.raw:

# ls -al /etc/extensions
total 68728
drwxr-xr-x. 2 root root     4096 Feb  5 17:46 .
drwxr-xr-x. 1 root root     4096 Feb  5 17:51 ..
lrwxrwxrwx. 1 root root        9 Feb  5 17:46 containerd-flatcar.raw -> /dev/null
--wxr-x---. 1 root root 70369280 Feb  5 17:46 docker.raw
lrwxrwxrwx. 1 root root        9 Feb  5 17:46 docker-flatcar.raw -> /dev/null
lrwxrwxrwx. 1 root root       32 Feb  5 17:46 oem-ami.raw -> /oem/sysext/oem-ami-3760.2.0.raw
# systemd-sysext list
NAME    TYPE PATH                        TIME
docker  raw  /etc/extensions/docker.raw  Mon 2024-02-05 20:28:02 UTC
oem-ami raw  /etc/extensions/oem-ami.raw Tue 2024-01-16 19:33:08 UTC
# systemd-sysext refresh
Using extensions 'docker', 'oem-ami'.
Unmerged '/usr'.
Merged extensions into '/usr'.
# docker --version
Docker version 24.0.9, build 2936816

---

@t-lo I also attempted to follow your guide to remediate the CVE and stumbled into a different error from @tgelter:

# systemd-sysext refresh
Failed to read metadata for image docker-24.0.9-x86-64: No medium found

Do you know what could be the source of this issue?

The sysext appears to be placed in the correct location:

# systemd-sysext list
NAME                 TYPE PATH                                     TIME
docker-24.0.9-x86-64 raw  /etc/extensions/docker-24.0.9-x86-64.raw Mon 2024-02-05 17:46:26 UTC
oem-ami              raw  /etc/extensions/oem-ami.raw              Tue 2024-01-16 19:33:08 UTC

Additionally, I attempted to replace Flatcar's inbuilt Docker/containerd with the symlinks:

# ls -al /etc/extensions
total 68728
drwxr-xr-x. 2 root root     4096 Feb  5 17:46 .
drwxr-xr-x. 1 root root     4096 Feb  5 17:51 ..
lrwxrwxrwx. 1 root root        9 Feb  5 17:46 containerd-flatcar.raw -> /dev/null
--wxr-x---. 1 root root 70369280 Feb  5 17:46 docker-24.0.9-x86-64.raw
lrwxrwxrwx. 1 root root        9 Feb  5 17:46 docker-flatcar.raw -> /dev/null
lrwxrwxrwx. 1 root root       32 Feb  5 17:46 oem-ami.raw -> /oem/sysext/oem-ami-3760.2.0.raw

And I disabled Torcx based off the docs:

# ls -al /etc/systemd/system-generators
total 16
drwxr-xr-x. 2 root root 4096 Feb  5 17:46 .
drwxr-xr-x. 1 root root 4096 Feb  5 17:46 ..
--wxr-x---. 1 root root    6 Feb  5 17:46 torcx-generator

# cat /etc/systemd/system-generators/torcx-generator
data:,

# docker --version
The program docker is managed by torcx, which did not run.

Extra debug information:

# cat /etc/os-release
NAME="Flatcar Container Linux by Kinvolk"
ID=flatcar
ID_LIKE=coreos
VERSION=3760.2.0
VERSION_ID=3760.2.0
BUILD_ID=2024-01-16-1847
SYSEXT_LEVEL=1.0
PRETTY_NAME="Flatcar Container Linux by Kinvolk 3760.2.0 (Oklo)"
ANSI_COLOR="38;5;75"
HOME_URL="https://flatcar.org/"
BUG_REPORT_URL="https://issues.flatcar.org"
FLATCAR_BOARD="amd64-usr"
CPE_NAME="cpe:2.3:o:flatcar-linux:flatcar_linux:3760.2.0:*:*:*:*:*:*:*"

# systemctl status systemd-sysext --no-pager -l
× systemd-sysext.service - Merge System Extension Images into /usr/ and /opt/
     Loaded: loaded (/usr/lib/systemd/system/systemd-sysext.service; disabled; preset: disabled)
     Active: failed (Result: exit-code) since Mon 2024-02-05 17:46:34 UTC; 5min ago
       Docs: man:systemd-sysext.service(8)
    Process: 1618 ExecStart=systemd-sysext merge (code=exited, status=1/FAILURE)
   Main PID: 1618 (code=exited, status=1/FAILURE)
        CPU: 19ms

Feb 05 17:46:33 localhost systemd[1]: Starting systemd-sysext.service - Merge System Extension Images into /usr/ and /opt/...
Feb 05 17:46:34 localhost systemd-sysext[1618]: Failed to read metadata for image docker-24.0.9-x86-64: No medium found
Feb 05 17:46:34 localhost systemd[1]: systemd-sysext.service: Main process exited, code=exited, status=1/FAILURE
Feb 05 17:46:34 localhost systemd[1]: systemd-sysext.service: Failed with result 'exit-code'.
Feb 05 17:46:34 localhost systemd[1]: Failed to start systemd-sysext.service - Merge System Extension Images into /usr/ and /opt/.

# SYSTEMD_LOG_LEVEL=debug systemd-sysext refresh
Opened '/etc/extensions/docker-24.0.9-x86-64.raw' in O_RDONLY access mode, with O_DIRECT enabled.
Successfully acquired /dev/loop3, devno=7:3, nr=3, diskseq=17
Opened /dev/loop3 (fd=5, whole_block_devnum=7:3, diskseq=17).
Successfully forked off '(sd-dissect)' as PID 2297.
Mounting /proc/self/fd/5 (squashfs) on /tmp/dissect-FCmMSK (MS_RDONLY|MS_NODEV "")...
Checking for /usr/lib/extension-release.d/extension-release.docker-24.0.9-x86-64: No such file or directory
/tmp/dissect-FCmMSK/usr/lib/extension-release.d/extension-release.docker does not have user.extension-release.strict xattr, ignoring.
Failed to mount dissected image: No medium found
Failed to read /etc/hostname of image: No such file or directory
/etc/machine-id file of image is empty.
Failed to read has-init-system boolean: Input/output error
(sd-dissect) failed with exit status 1.
Failed to read metadata for image docker-24.0.9-x86-64: No medium found

[pothos]

The name of the file or symlink under /etc/extensions/ should be docker.raw. In the ignition setup here you can see the files/symlinks: https://github.com/flatcar/sysext-bakery?tab=readme-ov-file#consuming-the-published-images
Here, we store the file in /opt/extensions/:

    - path: /opt/extensions/docker/docker-24.x.y-x86-64.raw
      contents:
        source: https://github.com/flatcar/sysext-bakery/releases/download/latest/docker-24.x.y-x86-64.raw

And here the excerpt for the symlink:

    - target: /opt/extensions/docker/docker-24.0.5-x86-64.raw
      path: /etc/extensions/docker.raw

The symlink helps to switch versions and I recommend to use systemd-sysupdate to update them:

    - path: /etc/sysupdate.docker.d/docker.conf
      contents:
        source: https://github.com/flatcar/sysext-bakery/releases/download/latest/docker.conf
    - name: systemd-sysupdate.timer
      enabled: true
    - name: systemd-sysupdate.service
      dropins:
        - name: docker.conf
          contents: |
            [Service]
            ExecStartPre=/usr/lib/systemd/systemd-sysupdate -C docker update
        - name: sysext.conf
          contents: |
            [Service]
            ExecStartPost=systemctl restart systemd-sysext

With the last drop in the switching of docker versions is done live, you can omit this to only switch on reboot (or manually).

[lib0xidium]

Are you planning to release for containerD too?

[krnowak]

Next alpha, beta and stable will have runc 1.1.12.

[krnowak]

And containerd 1.7.13.

[lib0xidium]

Perfect. Any news for the release?

[jepio]

@lib0xidium please follow this issue #1342

[chillTschill]

Next alpha, beta and stable will have runc 1.1.12.

Just to make sure: runc will not be updated with the next LTS, is that right?