May 2026 - wlug - list.wlug.org.nz

Linux bitten by second severe vulnerability in as many weeks
by Peter Reutemann 13 May '26

13 May '26

'Linux users have been bitten by yet another vulnerability that gives containers and untrusted users the ability to gain root access, marking the second time in as many weeks that a severe threat has caught defenders off guard. The threat, known as Dirty Frag, allows low-privilege users, including those using virtual machines, to gain root control of servers. Attacks are particularly suitable in shared environments, where a server is used by multiple parties. Hackers can also gain root as long as they have access to a separate exploit that gives a toehold into a machine. Exploit code was leaked online three days ago and works reliably across virtually all Linux distributions. Microsoft has said it has spotted signs that hackers are experimenting with Dirty Frag in the wild. The leaked exploit is deterministic, meaning it works precisely the same way each time it’s run and across different Linux distributions. It causes no crashes, making it stealthy to run. A vulnerability known as Copy Fail, disclosed last week with no patches available to end users, possesses the same characteristics. “The ‘Dirty Frag’ vulnerability presents an immediate and significant threat to Linux systems, as it allows unauthorized users to gain root access by exploiting unpatched kernel flaws,” researchers from security firm Aviatrix wrote Monday. “With proof-of-concept exploits publicly available and signs of limited in-the-wild exploitation, organizations must act swiftly to apply patches and implement mitigations to protect their systems from potential compromise.” Dirty Frag was discovered and disclosed late last week by researcher Hyunwoo Kim. The exploit chains together code for exploiting two vulnerabilities—tracked as CVE-2026-43284 and CVE-2026-43500. Shortly after the disclosure, someone else leaked key details, effectively making the vulnerability a zero-day. With that, Kim published the source code for the proof-of-concept exploit he had developed. While both vulnerabilities were patched in the Linux kernel, none of the distributions had incorporated the fix. At the time this post went live, several distributors had released patches. Known distributors included Debian, AlmaLinux, and Fedora. People who are interested in other distributions should check with the official provider.' -- source: https://arstechnica.com/security/2026/05/linux-bitten-by-second-severe-vuln… Cheers, Peter

2 1

60% of MD5 Password Hashes Are Crackable In Under an Hour
by Peter Reutemann 08 May '26

08 May '26

'In honor of World Password Day, Kaspersky researchers revisited their study on the crackability of real-world passwords and found that 60% of MD5-hashed passwords could be cracked in under an hour with a single Nvidia RTX 5090, and 48% could be cracked in under a minute. "The bottom line is that passwords protected only by fast hashing algorithms such as MD5 are no longer safe if attackers obtain them in a data breach," reports The Register. From the report: Much of the reason password hashes have become so easy to crack is password predictability. Per Kaspersky, its analysis of more than 200 million exposed passwords revealed common patterns that attackers can use to optimize cracking algorithms, significantly reducing the time needed to guess the character combinations that grant access to target accounts. In case you're wondering whether there's a trend to compare this to, Kaspersky ran a prior iteration of this study in 2024, and bad news: Passwords are actually a bit easier to crack in 2026 than they were a couple of years ago. Not by much, mind you -- only a few percent -- but it's still a move in the wrong direction. "Attackers owe this boost in speed to graphics processors, which grow more powerful every year," Kaspersky explained. "Unfortunately, passwords remain as weak as ever." "This World Password Day, the main message ought not to be to the users, who often have no choice but to use passwords anyway, but to the sites and providers that are requiring them to do so," said senior IEEE member and University of Nottingham cybersecurity professor Steven Furnell. His advice is that providers need to modernize their login systems and enforce stronger protections, because users are often stuck with whatever security options they're given.' -- source: https://yro.slashdot.org/story/26/05/07/1952206 Cheers, Peter

1 0

DAEMON Tools vs daemontools
by Lawrence D'Oliveiro 06 May '26

06 May '26

“Widely used Daemon Tools disk app backdoored in monthlong supply-chain attack” <https://arstechnica.com/security/2026/05/widely-used-daemon-tools-disk-app-…>: Kaspersky, the security firm reporting the supply-chain attack, said it began on April 8 and remained active as of the time its post went live. Installers that are signed by the developer’s official digital certificate and downloaded from its website infect Daemon Tools executables, causing the malware to run at boot time. Kaspersky didn’t explicitly say so, but based on technical details, the infected versions appear to be only those that run on Windows. Versions 12.5.0.2421 through 12.5.0.2434 are affected. Neither Kaspersky nor developer AVB could be contacted immediately for additional details. Checking my Debian repo, I find a set of related packages named “daemontools”. But it seems clear to me this “daemontools” has nothing to do with the “DAEMON Tools” product that is the subject of this security alert. To start with, the version numbers are quite different. Also, the latter is Windows-only <https://www.daemon-tools.cc/support/faq#system_requirements>, while the former makes it quite clear <https://cr.yp.to/daemontools.html> that it is “for managing UNIX services”.

1 0

Fixing A Service Dependency
by Lawrence D'Oliveiro 02 May '26

02 May '26

I don’t often have to restart my public-facing virtual server, but when I do, I have had trouble with one or two services not starting properly. The server picks up my mail via Postfix. From my office, I then run a periodic task which connects via POP to Dovecot on the server, and transfers the mail to my main office machine. This happens over an encrypted OpenVPN connection, so Dovecot itself doesn’t need to implement any encrypted transport, or accept connections on any publicly-accessible ports. One problem was, there was by default no coordination between the startup of the VPN connection and the startup of the Dovecot process. If the latter got going first, then it would fail to open a listening socket on the LAN-internal interface, because the VPN connection had not created that interface yet. Today I finally sat down and worked out a fix. This requires adding a dependency between the two services, via their systemd service configuration files. systemd offers a convenient method for allowing you to customize service configurations without having to completely replace their .service files. Instead, you create “drop-in” files, which amend the configuration in the desired ways. In this case, the original Dovecot service config file is /lib/systemd/system/dovecot.service, which I didn’t need to touch. Instead, I created the directory /etc/systemd/system/dovecot.service.d, to contain my amendments to the service definition. In here, I put a file which I decided to call geek-central.conf, which only needed to contain [Unit] Requires=openvpn-server(a)geek-central.service After=openvpn-server(a)geek-central.service (Note that the OpenVPN service definitions are “template” files, which means you can start multiple service instances from a common template, with a unique name after the “@” character. It’s up to the software implementing the service to use this instance name as a hint as to which configuration to choose for the service instance -- in this case, it looks for the VPN setup details in /etc/openvpn/server/geek-central.conf.) First I did a “systemctl daemon-reload”, followed by “systemctl show dovecot.service”, just to confirm it was picking up the configuration changes correctly -- namely, that the “Requires=” and “After=” entries showed the combination of the default settings and my amendments. Then, of course, to do a proper test, I had to reboot the server. Which worked. I also did a similar thing to fix a race condition between the startup of the SQLGrey mail greylisting service and the database server it is using. The former requires the latter, but the default service configuration doesn’t specify this, again leading to startup failures -- I would class this as a configuration bug. A fix for this was similarly easy.

1 0

New Linux 'Copy Fail' Vulnerability Enables Root Access On Major Distros
by Peter Reutemann 02 May '26

02 May '26

'A newly disclosed Linux kernel flaw dubbed "Copy Fail" can let a local, unprivileged attacker gain root access on major Linux distributions, with researchers claiming the bug affects kernels shipped since 2017. "The POC exploit works out of the box today, but a future version that can escape from containers like Docker is promised soon," writes Slashdot reader tylerni7. "Technical details are available here." Slashdot reader BrianFagioli shares a report from NERDS.xyz: A newly disclosed Linux kernel vulnerability called Copy Fail (CVE-2026-31431) allows an unprivileged user to gain root access using a tiny 732-byte script, and it works with unsettling consistency across major distributions. Unlike older exploits that relied on race conditions or fragile timing, this one is a straight-line logic flaw in the kernel's crypto subsystem. It abuses AF_ALG sockets and splice to overwrite a few bytes in the page cache of a target file, such as /usr/bin/su. Because the kernel executes from the page cache, not directly from disk, the attacker can inject code into a setuid binary in memory and immediately escalate privileges. What makes this especially concerning is how quiet it is. The file on disk remains unchanged, so standard integrity checks see nothing wrong, while the in-memory version has already been tampered with. The same primitive can also cross container boundaries since the page cache is shared, raising the stakes for multi-tenant environments and Kubernetes nodes. The underlying issue traces back to an in-place optimization added years ago, now being rolled back as part of the fix. Until patched kernels are widely deployed, this is one of those bugs that feels less like a theoretical risk and more like a practical, reliable path to full system compromise. ' -- source: https://it.slashdot.org/story/26/04/30/207231 Cheers, Peter

1 0

Hackers Are Actively Exploiting a Bug In cPanel, Used By Millions of Websites
by Peter Reutemann 02 May '26

02 May '26

'Hackers are actively exploiting a critical cPanel and WHM vulnerability, tracked as CVE-2026-41940, that allows remote attackers to bypass the login screen and gain full administrative access to affected web servers. Major hosts including Namecheap, HostGator, and KnownHost have taken mitigation steps or patched systems, but cPanel is urging all customers and web hosts to update immediately because the software is widely used across millions of websites. TechCrunch reports: cPanel and WHM are two software suites used for managing web servers that host websites, manage emails, and handle important configurations and databases needed to maintain an internet domain. The two suites have deep-access to the servers that they manage, allowing a malicious hacker potentially unrestricted access to data managed by the affected software. Given the ubiquity of the cPanel and WHM software across the web hosting industry, hackers could compromise potentially large numbers of websites that haven't patched the bug. Canada's national cybersecurity agency said in an advisory that the bug could be exploited to compromise websites on shared hosting servers, such as large web hosting companies. The agency said that "exploitation is highly probable" and that immediate action from cPanel customers, or their web hosts, is necessary to prevent malicious access. [...] One web hosting company says it found evidence that hackers have been abusing the vulnerability for months before the attempts were discovered.' -- source: https://it.slashdot.org/story/26/05/01/0631257 Cheers, Peter

1 0