Vue normale

Reçu avant avant-hier

New Moderate Linux Flaw Allows Password Hash Theft Via Core Dumps in Ubuntu, RHEL, Fedora

2 juin 2025 à 04:34
An anonymous reader shared this report from The Hacker News: Two information disclosure flaws have been identified in apport and systemd-coredump, the core dump handlers in Ubuntu, Red Hat Enterprise Linux, and Fedora, according to the Qualys Threat Research Unit (TRU). Tracked as CVE-2025-5054 and CVE-2025-4598, both vulnerabilities are race condition bugs that could enable a local attacker to obtain access to access sensitive information. Tools like Apport and systemd-coredump are designed to handle crash reporting and core dumps in Linux systems. "These race conditions allow a local attacker to exploit a SUID program and gain read access to the resulting core dump," Saeed Abbasi, manager of product at Qualys TRU, said... Red Hat said CVE-2025-4598 has been rated Moderate in severity owing to the high complexity in pulling an exploit for the vulnerability, noting that the attacker has to first win the race condition and be in possession of an unprivileged local account... Qualys has also developed proof-of-concept code for both vulnerabilities, demonstrating how a local attacker can exploit the coredump of a crashed unix_chkpwd process, which is used to verify the validity of a user's password, to obtain password hashes from the /etc/shadow file. Advisories were also issued by Gentoo, Amazon Linux, and Debian, the article points out. (Though "It's worth noting that Debian systems aren't susceptible to CVE-2025-4598 by default, since they don't include any core dump handler unless the systemd-coredump package is manually installed.") Canonical software security engineer Octavio Galland explains the issue on Canonical's blog. "If a local attacker manages to induce a crash in a privileged process and quickly replaces it with another one with the same process ID that resides inside a mount and pid namespace, apport will attempt to forward the core dump (which might contain sensitive information belonging to the original, privileged process) into the namespace... In order to successfully carry out the exploit, an attacker must have permissions to create user, mount and pid namespaces with full capabilities." Canonical's security team has released updates for the apport package for all affected Ubuntu releases... We recommend you upgrade all packages... The unattended-upgrades feature is enabled by default for Ubuntu 16.04 LTS onwards. This service: - Applies new security updates every 24 hours automatically. - If you have this enabled, the patches above will be automatically applied within 24 hours of being available.

Read more of this story at Slashdot.

Why Windows 7 Took Forever To Load If You Had a Solid Background

Par :BeauHD
1 mai 2025 à 03:30
An anonymous reader quotes a report from PCWorld: Windows 7 came onto the market in 2009 and put Microsoft back on the road to success after Windows Vista's annoying failures. But Windows 7 was not without its faults, as this curious story proves. Some users apparently encountered a vexing problem at the time: if they set a single-color image as the background, their Windows 7 PC always took 30 seconds to start the operating system and switch from the welcome screen to the desktop. In a recent blog post, Microsoft veteran Raymond Chen explains the exact reason for this. According to him, a simple programming error meant that users had to wait longer for the system to boot. After logging in, Windows 7 first set up the desktop piece by piece, i.e. the taskbar, the desktop window, icons for applications, and even the background image. The system waited patiently for all components to finish loading and received feedback from each individual component. Or, it switched from the welcome screen to the desktop after 30 seconds if it didn't receive any feedback. The problem here: The code for the message that the background image is ready was located within the background image bitmap code, which means that the message never appeared if you did not have a real background image bitmap. And a single color is not such a bitmap. The result: the logon system waited in vain for the message that the background has finished loading, so Windows 7 never started until the 30 second fallback activated and sent users to the desktop. The problem could also occur if users had activated the "Hide desktop icons" group policy. This was due to the fact that such policies were only added after the main code had been written and called by an If statement. However, Windows 7 was also unable to recognize this at first and therefore took longer to load.

Read more of this story at Slashdot.

❌