This Week in Security: BatBadBut, DLink, and Your TV Too

Estimated reading time: 6 minutes

• D-Link E-Waste
• And Your TV, Too!
• Mostly Luck — And Curiosity
• Libfreeimage
• Bits and Bytes
• About The Author

So first up, we have BatBadBut, a pun based on the vulnerability being “about batch files and bad, but not the worst.” It’s a weird interaction between how Windows uses cmd.exe to execute batch files and how argument splitting and character escaping normally works. And what is apparently a documentation flaw in the Windows API.

When starting a process, even on Windows, the new executable is handed a set of arguments to parse. In Linux and friends, that is a pre-split list of arguments, the argv array. On Windows, it’s a single string, left up to the program to handle. The convention is to follow the same behavior as Linux, but the cmd.exe binary is a bit different. It uses the carrot ^ symbol instead of the backslash to escape special symbols, among other differences. The Rust devs took a look and decided that there are some cases where a given string just can’t be made safe for cmd.exe, and opted to just throw an error when a string met this criteria.

And that brings us to the big questions. Who’s fault is it, and how bad is it? I think there’s some shared blame here. The Microsoft documentation on CreateProcess() strongly suggests that it won’t execute a batch file without cmd.exe being explicitly called. On the other hand, This is established behavior, and scripting languages on Windows have to play the game by Microsoft’s rules. And the possible problem space is fairly narrow: Calling a batch file with untrusted arguments.

Almost all of the languages with this quirk have either released patches or documentation updates about the issue. There is a notable outlier, as the Java language will not receive a fix, not deeming it a vulnerability. It’s rather ironic, given that Java is probably the most likely language to actually find this problem in the wild.

D-Link E-Waste

A Pair of Vulnerabilities have been announced for D-Link NAS units, that together make for a trivial unauthorized Remote Code Execution (RCE) scenario. The four known-vulnerable models are all from the DNS-300 series, and all of them are well beyond their End of Service dates. These devices are on the Internet, and scanning and exploitation has started in the wild.

Due to the age of the units, D-Link will not be issuing patches for the hardcoded credentials and command injection issues that were found. And that puts these devices strictly in the Do Not Connect category. A terrifying snippet taken from the DNS-327L manual: “The DNS-327L supports UPnP port forwarding which configures port forwarding automatically on your UPnP-enabled router.” No wonder there’s nearly 100k of these devices on the Internet. The official D-Link advice is to retire and replace.

And Your TV, Too!

Multiple versions of the WebOS TV firmware have a series of problems accessible over the local network. CVE-2023-6317 is a fun one, where an account with no privileges can be silently created, and then the key generated upon account creation can be immediately re-used to create another account, with full permissions.

And then there’s a trio of vulnerabilities that allow for command execution. The good news is that it’s only accessible from the local network, and that TVs aren’t known for UPNP shenanigans quite like NASs are. And the real silver lining, if you have one of the vulnerable TVs? There’s a WebOS Homebrew scene!

Mostly Luck — And Curiosity

[Fang-Pen Lin] was working on a project using ZeroMQ, a universal message library. This led to excitement about CurveZMQ, which among other things, allows embedding arbitrary data into the metadata field of an authenticated message. And then curiosity forced the question, how much data can we put in there? To find the answer required a dive into the ZeroMQ source. And sure enough, there it was, a fixed-size static buffer, neatly defining how much data goes in the metadata field. But what would happen if we add a bit more data then we’re supposed to? Kaboom. The buffer overflows, the program crashes, and that’s how [Lin] discovered a critical security bug in ZeroMQ.

Now, this is more than just luck. It’s a combination of knowing enough to recognize the issue, and having the curiosity to look in just the right spot. The issue was rapidly fixed, and that was that, way back in 2019. Why are we talking about it now? Because that combination of skill, curiosity, and luck is how the XZ backdoor was discovered. And how pretty much every vulnerability or bug gets found and fixed. Follow the link for the rest of [Jin]’s thoughts on the matter.

Libfreeimage

The Libfreeimage library has a pair of buffer overflows, triggered by parsing malicious XPM images. In this case, it’s the color names in those files, which are copied into a fixed size buffer, and can be easily overflowed. And to make it worse, this can trigger an error message, which can lead to yet another overflow. It’s likely these issues could be used to achieve arbitrary code execution. This one could be quite a sneaky problem, as libfreeimage has been around for a long time, with the first release coming in January of 2000, and the XPM loader getting added in 2003. That’s a long time for a library to get built into other projects and binaries.

Bits and Bytes

Using the appropriate username of [1337_wannabe], a contributor to the Wordfence Bug Bounty Extravaganza earned a cool $5500 for a pre-auth SQL injection in the LayerSlider WordPress plugin. The was reported on March 25th, and a fix was pushed on the 27th, in an impressive show. Turns out you are pretty leet, [1337_wannabe].

On the other hand, when there’s no CVE, companies don’t get in much of a hurry to push updates. The Lighttpd lightweight web server pushed fixes for use-after-free bugs way back in 2018, but didn’t bother to get CVE numbers assigned, or make a big announcement of the vulnerabilities. This is typical for internally discovered issues like this. The problem here is that lighttpd gets bundled into other software, like Baseboard Management Controllers. And so for five years, Supermicro, Lenovo, and others have been shipping vulnerable BMC implementations, because nobody bothered to grab the latest version. On the plus side, these issues don’t lead directly to code execution, but they do result in data disclosure. The morals of this one? Update your code! And don’t put your BMC on the Internet!

And finally, in the funny-yet-problem category, the Twitter to X rebranding process hit a snag, when all domains ending in “twitter.com” were visually re-written as ending in “x.com”. AKA, a tweet with a link to netflitwitter.com would appear in the tweet as netflix.com, but still actually point to the bogus domain when clicked. Hilarious, and a real test-the-code-in-production sort of moment that I can really relate to. But it’s a problem particularly for the other brands that happen to end with an X, like Netflix and others, as this was prime phishing and spoofing risk while it was still a problem.

About The Author

See author's posts