I learned a new acronym while reading about a set of flaws in the Dell BIOS update system. Because Dell has patched their driver, but hasn’t yet revoked the signing keys from the previous driver version, it is open to a BYOVD attack.

BYOVD, Bring Your Own Vulnerable Driver, is an interesting approach to Windows privilege escalation. 64-bit versions of Windows have a security feature that blocks unsigned kernel drivers from the kernel. The exploit is to load an older, known-vulnerable driver that still has valid signatures into the kernel, and use the old vulnerabilities to exploit the system. The caveat is that even when a driver is signed, it still takes an admin account to load a driver. So what use is the BYOVD attack, when it takes administrative access to pull off?

SentinelLabs is witholding their proof-of-concept, but we can speculate. The particular vulnerable driver module lives in the filesystem at C:\Windows\Temp, a location that is writable by any process. The likely attack is to overwrite the driver on the filesystem, then trigger a reboot to load the older vulnerable version. If you’re still running Windows on your Dell machines, then make sure to go tend to this issue.

Yet Another Spectre Flaw

Spectre, the speculative execution vulnerability, has struck again. Where previous versions leaked data via cached memory, this iteration leaks memory through the micro-op cache. I’ve often joked that x86 processors don’t really run the x86 instruction set, they emulate it. It’s partially true, as part of the execution pipeline is translating the x86 macro-ops into processor specific “RISC-like micro-ops”. This translation process has the potential to be a complex operation, so modern processors have a cache to avoid repeating the process for repeated instructions.

The researchers, working from the University of Virginia and University of California, San Diego have published their paper on the technique. There is some disagreement about the seriousness of this new technique, with the researchers claiming that they can bypass all the current built-in Spectre protections. Intel has stated that the new technique does not bypass their existing mitigations, and AMD hasn’t yet made a statement about the paper. Time will tell how much work will actually be needed to mitigate yet another problem with speculative execution.

Android Updates

This month’s Android security patches bring a trio of serious bugs. CVE-2021-0473 is a set of problems in how the Android system handles NFC tags. Invalid NFC messages could result in a double free, a buffer overflow, and memory disclosure. The primary solution appears to be just dropping NFC packets that don’t appear valid, rather than trying to handle them anyway.

CVE-2021-0474 and CVE-2021-0475 are both problems in Bluetooth handling. These are both pretty simple. The first is a easy-to-do coding error: checking a packet’s length using sizeof(p_pkt->len). The size of the len member is fixed — they really want to just read the value. The second Bluetooth bug is a pair of missing return statements, leading to a use-after-free when hitting certain error conditions.

More Ambiguous IPs

The insanity that is octal-formatted IP addresses appears to be the gift that keeps on giving, and this time it’s the Python ipaddress library. Just over two years ago, this Python3 library was changed to tolerate a leading “0”s in IP addresses. As we’ve previously covered, this leads to confusion between the different layers of an application, where a security check might allow an address that is understood as a different address when it is acted on. The Python devs have gone with what I consider to be the correct solution: invalidating all IP addresses with leading “0”s. The octal address format was never RFC compliant, and should be avoided anyway. We’ll likely return to this story multiple times, as I’ve been told that several other languages and libraries have the exact same problem.

Turning Off the Security System

It’s a trope that we normally laugh at, when the geeky sidekick hacks into a house’s security system to disable it from afar. But, apparently in the case of an ABUS Secvest system, it’s really that easy.

A Secvest system needs port 4433 forwarded to the system in order to manage it from the internet. [Niels Teusink] points out that this is an advantage, in that the system can be remotely administered without relying on a cloud system. The downside is that this HTTPS interface is particularly broken. Multiple endpoints on the system can be accessed without authentication, including one that dumps the system configuration. Included in that configuration data? The cleartext user PINs needed to control the system.

For one more movie-worthy trick, many systems are configured with Dynamic DNS. The update credentials are also in that configuration data, so not only could an attacker disable the system, he can also take over the Dynamic DNS name, to play a loop of uninteresting video whenever the owner tries to pull up their cameras remotely. It’s a hack worthy of a bad Hollywood blockbuster.

21nails in Exim Email

The Exim mail server was started in 1995 as a Mail Transfer Agent for Unix machines. Qualys audited Exim, and the results weren’t pretty. Qualys calls the result 21Nails, as there are 21 serious vulnerabilities found in the effort, many of which existing as far back as the git history of the project. While the report doesn’t include PoC code, they will likely be quickly developed independently, so if you run Exim, go update your servers now.

ExifTool

And lastly, we have a big problem in ExifTool:

Anyone using ExifTool make sure to update to 12.24+ as CVE-2021-22204 can be triggered with a perfectly valid image (jpg, tiff, mp4 and many more) leading to arbitrary code execution! pic.twitter.com/VDoybw07f5

— William Bowling (@wcbowling) April 24, 2021

The patch makes it fairly clear what was going on. Strings with special characters were handled with a combination of regex and an eval statement. That last technique is almost certainly the problem. If an attacker could inject Perl code into the string being evaluated, and escape the “quotes jail” (shout out to @bananabr for that turn of phrase), then running arbitrary Perl code is trivial.

This one has the potential to be really problematic, as ExifTool likely runs on the backend of many sites, pulling metadata out of uploaded images. Any such site can now trivially be compromised by uploading a trapped image.