This Week in Security: CVSS 0, Chwoot, and Not in the Threat Model
This week a reader sent me a story about a CVE in Notepad++, and something isn’t quite right. The story is a DLL hijack, a technique where a legitimate program’s Dynamic Link Library (DLL) is replaced with a malicious DLL. This can be used for very stealthy persistence as well as escalation of privilege. This one was assigned CVE-2025-56383, and given a CVSS score of 8.4.
The problem? Notepad++ doesn’t run as a privileged user, and the install defaults to the right permissions for the folder where the “vulnerable” DLL is installed. Or as pointed out in a GitHub issue on the Proof of Concept (PoC) code, why not just hijack the notepad++ executable?
This is key when evaluating a vulnerability write-up. What exactly is the write-up claiming? And what security boundary is actually being broken? The Common Weakness Enumeration (CWE) list can be useful here. This vulnerability is classified as CWE-427, an uncontrolled search path element — which isn’t actually what the vulnerability claims, and that’s another clue that something is amiss here. In reality this “vulnerability” applies to every application that uses a DLL: a CVSS 0.
Smish Boxes
There’s a trend to replace land lines with cellular modems. While wearing my phone tech hat, I’ve even installed a few cellular routers in hotel telecom closets. It turns out there’s a potential problem with that particular arrangement. Hotels and other commercial installations often assign a public IP address to each piece of equipment, and as a result it’s not uncommon for that equipment to be directly exposed to the Internet. And what happens when cellular routers are exposed to the Internet, sometimes with vulnerabilities or even default credentials? Naturally, scammers use them to send spammy SMS messages.
The scale of the problem is surprising. After researchers at Sekoia discovered the problem, they discovered 18,000 of these devices accessible on the Internet. It seems like this campaign may be responsible for the majority of the SMS spam being sent in modern smishing campaigns. It also appears that there may be an unknown 0-day being exploited in the campaign.
VMWare
VMware just fixed CVE-2025-41244, a local privilege escalation vulnerability that has been in use in the wild since at least October of last year. This vulnerability is in the service discovery feature of VMware Aria. The idea is that the installed VMware Tools can discover running services and probe for version numbers.
On a Linux guest, this probe works by listing the currently running processes, and if the a process matches one of the regular expressions, that process is run with the -v flag. As root. Yes, this vulnerability that was being actively exploited in the wild by a Chinese threat actor for over a year, was as simple as an over-matching regex and carelessly running binaries as root. The trick favored by the attackers was to place a malicious binary at /tmp/httpd, run it as a regular user, and just wait for the VMware tooling to come along and run it as root.
Sudo Chwoot
The maintainers behind sudo fixed a pair of vulnerabilities back in June that allowed a local attacker to escalate privileges. The most interesting of the two abuses is in the handling of the chroot option, resulting in an attack [Rich Mirch] refers to as “chwoot”.
The actual weakness is that sudo would use the chroot() system call while setting up the chroot environment, prior to dropping privileges. In this state, sudo performs Name Service Switch calls as root, which results in looking for /etc/nsswitch.conf inside the chroot directory. This config file can trigger a shared library load, and since it’s happening in the context of a chroot, that library is also first loaded from the chroot directory if it exists there, resulting in a handy escalation to root.
This behavior is enabled for all users by default, resulting in a serious vulnerability on many Linux machines. It was fixed and disclosed back in June, but has now been added to the CISA list of known exploited vulnerabilities.
Not in the Threat Model
Intel and AMD both have trusted computing solutions for encrypted VMs, that among other things, encrypt the bits in memory so even a compromised kernel can’t extract data from the running VM. The approaches from both companies are similar, using symmetric encryption with the memory location as part of the encryption Initialization Vector (IV). This means that while the same key is in use, a plaintext value in a given memory location will always be represented by the same encrypted value. Two pieces of research came out this week suggesting that this codebook-like behavior has security ramifications.
Before we dive into the rest of the details, it’s worth pointing out that asymmetric encryption is likely not a viable option for VM memory encryption, due to the processing latency overhead. The exploit here is to physically connect to the memory sticks inside a target computer, and record the encrypted bits. In some cases, an attacker can later run a malicious VM on the same hardware, and use the physical hack to replay the captured bits, allowing easy decryption. Another option is to replay the VM attestation report, falsely claiming that the virtual machine is still fully protected.
What’s initially surprising is that both Intel and AMD have maintained that their SGX and SEV-SNP systems are not intended to protect against physical access. But seeing what is possible with physical modification to system memory, it’s no longer a surprising line to draw. The other interesting note is that so far these attacks are limited to DDR4, as DDR5 memory has a higher data rate, making the entire operation even more difficult.
Bit and Bytes
Red Hat has confirmed that one of its GitLab instances was compromised by Crimson Collective, leading to the exfiltration of over 500 GB of data. This seems to include customer data related to consulting contracts.
RCE Security dug into a product called TRUfusion Enterprise, a data transfer solution that is marketed as undergoing regular audits. It came as a surprise that they found four vulnerabilities that could be called low-hanging fruit. The takeaway: not all audits are created equal, and there’s no guarantee that this style of code review will catch every bug.
Our last two links are both about memory management. The first is from Cybervelia, looking at how to find uninitialized memory access with just a program binary and no source code. Binary Ninja is the tool that really shines here, but it’s certainly not an easy task.
The other is the latest from Google’s Project Zero, taking a look at some non-obvious ways to defeat Address Layout Randomization using careful analysis of hash tables. Very in-depth work, and on-brand for Project Zero. Enjoy!
hackaday.com/2025/10/03/this-w…
