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.
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.
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.
16 thoughts on “This Week In Security: BYOVD, Spectre Vx, More Octal Headaches, And ExifTool”
>I’ve often joked that x86 processors don’t really run the x86 instruction set, they emulate it.
It is emulation if you have different hardware.
e.g. 68xxx FPU emulation for a processor is done in exception handling when it encounters an instruction that was meant for the missing FPU.
Speaking of x86 emulation on other CPUs.
Modern processors don’t actually execute the x86 machine code directly anymore. There is a front-end component that dynamically recompiles them into RISC micro-ops. This is literally an emulation technique, hence the joke.
“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.”
ARM, and of course people mention RISC as a counter-point.
ARM chips at least some of them also do speculative, so they are not universally safer, though some of the flaws found may need more work or not apply they still have the core security blunder.
I wonder how long it will be until system designers realise speculative execution is just not a good idea for anything security related, it opens so many cans of worms and now people have noticed they keep finding more.. At best speculative should be a well isolated co-processor arrangement to boost performance in the tasks its given.
Yes. In my opinion, speculative execution is one of the worst ideas ever. Nothing like good old cycle counting for precise timing.
ExifTool: Isn’t there a security mecanism called “tainting” or sth in Perl? Does it not work or did they not use it? As far as i understand the use eval to parse user supplied stuff, it seems basic knowledge that this is dangerous??
Its stuff like Spectre that make me seriously consider pulling my old SPARC box out of retirement…
For the EXIM bugs, I am constantly surprised at the the security flaws in software like that, SMTP is one of the oldest protocols still in use, how are people still screwing it up?
They’re not “still” screwing it up. They screwed it up yonks ago when Exim was first written, and it’s never been spotted and fixed until now.
I was more talking about how I keep seeing bug reports for other SMTP servers as well, I still see sendmail and postfix bugs, even OpenSMTPd still pushes code updates to plug security holes.
I guess software must be difficult or something. Specifically, complex software without serious flaws.
One of the worst flaws in SMTP is it allows putting SMTP in the server name. One of the worst things ever for tech support because about 50% of people are incapable of typing S M T P when told to during a support call.
What they repeat back… SMPT, FNBD, SNPT SNBV… you get the idea.
ISP IT departments PLEASE do not name your SMTP server with SMTP! Been 20 years since I worked a helldesk and that still makes me cringe thanks to the shorthand for Symmetric Mail Transport Protocol being four of the worst letters in the English alphabet for being confusable with other letters.
Automatic Electronic Letter Carrier. AELC would be a string of four letters I’d expect most people (especially senior citizens with bad hearing) would be less likely to confuse with others or transpose.
Might be easier to name it SierraMikeTangoPapa as it would be easier to remember for the initiated.
“The primary solution appears to be just dropping NFC packets that don’t appear valid, rather than trying to handle them anyway.”
If every program did this, security would be substantially better. Seriously, this should be the default behavior.
But then you break the one edge-case oddball (ab)use of NFC tags by some proprietary app that some large corporation uses and they get mad and complain
“If every program did this, security would be substantially better. Seriously, this should be the default behavior.”
*cough* browsers *cough*
Please be kind and respectful to help make the comments section excellent. (Comment Policy)