Security issue CVE-2024-2905: World-readable /etc/shadow & /etc/gshadow on Fedora CoreOS, IoT, Atomic Desktops (including Silverblue & Kinoite)

News & Announcements
, , , , , , ,
1

Due to a bug in rpm-ostree, the /etc/shadow, /etc/shadow-, /etc/gshadow and /etc/gshadow- files in Fedora CoreOS, IoT, Atomic Desktops have the world-readable bit set.

Affected versions

All Fedora CoreOS nodes installed starting from the following versions are impacted:

  • stable: 38.20230902.3.0
  • testing: 38.20230902.2.1
  • next: 38.20230902.1.1

Fedora IoT and Fedora Atomic Desktops (Silverblue, Kinoite, Sway Atomic, Budgie Atomic) systems that were installed from Fedora 39 and later release media and ISOs are affected.

This only impacts new installations and not updated systems thus systems installed from artifacts before those releases are not impacted (Fedora 38 or earlier).

This only impacts systems where a password is set. Systems where only SSH keys were used are not impacted by this vulnerability even though it is present on the node.

On systems with SELinux enabled and in enforcing mode, access to those files is limited to unconfined (usually interactive) users, unconfined systemd services and privileged containers. Confined daemons, users and containers are not able to access them.

Fixed versions

The following Fedora CoreOS versions fix the issue and include a systemd unit to fix existing systems on update:

  • stable: 39.20240322.3.1
  • testing: 39.20240407.2.0
  • next: 40.20240408.1.0

Fedora CoreOS systems with automatic updates enabled will automatically get the update starting on 2024-04-10 14:00 UTC.

Fedora Atomic Desktops version 39.20240410.1 includes the fix. The fix is still pending for Fedora Atomic Desktops 40 (not officially released yet).

An update with the fix for Fedora IoT is still pending.

Workaround / immediate fix

To immediately fix existing systems, you can run the following command as root:

chmod --verbose 0000 /etc/shadow /etc/gshadow /etc/shadow- /etc/gshadow-

As a precaution, we recommend rotating all user credentials stored in those files.

References

GitHub Security Advisory: World-readable /etc/shadow, /etc/shadow-, /etc/gshadow, /etc/gshadow- · Advisory · coreos/rpm-ostree · GitHub
Red Hat Security Advisory: cve-details
Fedora CoreOS issue: Fix rpm-ostree CVE-2024-2905 (world-readable `/etc/[g]shadow[-]`) · Issue #1705 · coreos/fedora-coreos-tracker · GitHub

11 Likes
2

Cross-linking:

3 Likes
4

Added atomic-desktops-team, budgie-team, sway-team

5

From Project Discussion to News & Announcements

6

Added atomic-desktops-announce

7

Actually, we default to YesCrypt since F37 (Changes/yescrypt as default hashing method for shadow - Fedora Project Wiki). When passwords hashes with yescrypt are leaked, this is not a big issue. The expectation is that the hash is hard to crack, unless the passwords are very weak. Since this only affects F39 or later, we don’t expect passwords hashes with weaker algorithms on those systems. So the issue is not terribly serious.

3 Likes
8

Thanks @zbyszek for pointing that out.

For FCOS we also instruct people to use mkpasswd --method=yescrypt in the docs when configuring users via Ignition, so that’s promising.

1 Like
9

This topic was automatically closed after 29 days. New replies are no longer allowed.