Package: gnome-keyring Version: 3.36.0-1 Severity: important Tags: security upstream
gnome-keyring has several vulnerabilities with regard to its handling of its encrypted data files. First, the code to verify the integrity hash is done with memcmp. This is not safe against timing attacks, so an attacker can tamper with the data and determine how much of the hash matches based on the amount of time it takes[0]. This comparison should be done in a constant-time way. Second, because the integrity algorithm used is MD5, which is vulnerable to collisions, it doesn't uniquely identify a sequence of bytes. Consequently, the padding must be checked to be zero, and it must be done in constant time with the actual integrity algorithm, such that a failure of either takes exactly the same amount of time. Third, the metadata that occurs unencrypted in the file is hashed with MD5. Since MD5 is cheap to compute, an attacker can guess to see if the items they want to access are in the keyring without needing to decrypt the data. The keys themselves are also stored unencrypted, which makes it easy to determine which types of objects and how many of each type are stored in the keyring. For example, GnuPG stores a "keygrip" attribute. This violates user privacy and leaks a significant amount of data. All of this data should be stored encrypted. Even storing both keys and values as MACs using a secret key would leak which keys and values are repeated, which in many cases would still leak a significant amount of information. Fourth, the metadata stored unencrypted is also stored without any sort of integrity check. As a result, an attacker can modify it at will without any detection whatsoever. All data stored in the file, including version numbers, algorithm identifiers, and other structural content, as well as encrypted data, should be protected either by an AEAD encryption algorithm or a strong MAC (such as HMAC with SHA-2, SHA-3, or BLAKE2). This was originally reported to the Debian Security Team on February 3, but they were unable to issue a CVE, so I reported it to the GNOME Security Team on February 4. The response was the gnome-keyring team is "aware of those issues" but they "don't think those issues are severe enough to urge an immediate fix" and plan to address them at an unspecified point in the future. Since 45 days have elapsed since the initial report and no fix is forthcoming[1], I've opened this bug to disclose this issue publicly. This is probably severity grave, but I don't have a true proof-of-concept demonstrating that it allows access to user accounts, so I opted for important. Feel free to change as you see fit. Please ensure CVEs are issued for these bugs. [0] This can be a problem with an untrusted container with the user's home directory mounted in it. There's documentation for VS Code that tells people how to do exactly this, so it's clearly a common situation. [1] https://github.com/bk2204/dev-practices/tree/master/security-research -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-keyring depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.16-2 ii dbus-x11 [dbus-session-bus] 1.12.16-2 ii dconf-gsettings-backend [gsettings-backend] 0.36.0-1 ii gcr 3.36.0-2 ii libc6 2.30-4 ii libcap-ng0 0.7.9-2.1+b2 ii libcap2-bin 1:2.33-1 ii libgck-1-0 3.36.0-2 ii libgcr-base-3-1 3.36.0-2 ii libgcrypt20 1.8.5-5 ii libglib2.0-0 2.64.1-1 ii p11-kit 0.23.20-1 ii pinentry-gnome3 1.1.0-3+b1 Versions of packages gnome-keyring recommends: ii gnome-keyring-pkcs11 3.36.0-1 ii libpam-gnome-keyring 3.36.0-1 gnome-keyring suggests no packages. -- no debconf information -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
signature.asc
Description: PGP signature