There are a few binaries that wind up running in a bunch of places, silently do their jobs, and being easily forgotten about. ImageMagick is used on many servers for image conversion and resizing, and tends to run automatically on uploaded images. Easily forgotten, runs automatically, and with arbitrary inputs. Yep, perfect target for vulnerability hunting. And the good folks at Metabase found two of them.

First up is CVE-2022-44267, a Denial of Service, when ImageMagick tries to process a rigged PNG that contains a textual chunk. This data type is usually used for metadata, and can include a profile entry for something like EXIF data. If this tag is specified inside a text chunk, ImageMagick looks to the given value as a filename for finding that profile data. And notably, if that value is a dash -, it tries to read from standard input. If the server’s image processing flow doesn’t account for that quirk, and virtually none of them likely do, this means the ImageMagick process hangs forever, waiting for the end of input. So while that’s not usually a critical problem, it could be used for a resource exhaustion attack.

But the real problem is CVE-2022-44268. It’s the same trick, but instead of using - to indicate standard input, the processed image refers to a file on the server filesystem. If the file exists, and can be read, the contents are included in the image output. If the attacker has access to the image, it’s a slick data leak — and obviously a real security problem. If a server doesn’t have tight file permissions and isolation, there’s plenty of sensitive information to be found and abused.

The fix landed back in October 2022, and was part of the 7.1.0-52 release. There’s a bit of uncertainty about which versions are vulnerable, but I wouldn’t trust anything older than that version. It’s a pretty straightforward flaw to understand and exploit, so there’s a decent chance somebody figured it out before now. The file exfiltration attack is the one to watch out for. It looks like there’s an Indicator of Compromise (IoC) for those output PNGs: “Raw profile type”.

vBulletin

vBulletin had an interesting problem last year, where an unauthenticated user can trigger a deserialization of user-controlled data. We normally think of this bug showing up in Java applications, but it’s a problem in PHP, too. An object can include code, and serialization bundles up the entire object into a string to transmit it. Deserialization does the opposite, populating data and code into a new object. When it comes to PHP, there’s an easy way and a hard way to take advantage of deserialization. The easy way is to populate a magic function, like __wakeup() or __unserialize(). Those functions would typically run automatically when unpacking the data, but the vBulletin code is hardened against this attack, throwing an exception instead of blindly executing.

That leaves the more complicated approach. Objects can contain other objects, of arbitrary classes. And while none of those classes may be vulnerable to the simple magic function exploit, there’s a whole library of gadget chains that target known library classes in clever ways. And it just so happens that one of those vulnerable libraries is part of the vBulletin install: Monolog. So, add the exploit, and pop the install, yes? No. See, vBulletin is written pretty defensively, and while it is present, Monolog is disabled by default, and unreachable from our deserialization context.

And this is where this attack becomes really clever. Modern PHP libraries tend to have an autoloader function. So rather than a block of include "library/class.php"; code, files and directories are organized by class name, and a lookup function will load each as needed in the source file. Pages that don’t actually use all those libraries may load significantly faster, with less setup to perform. And interestingly, in up-to-date PHP, those autoload definitions can be chained together, so a library can define its own autoloader function. Remember that Monolog library that is vulnerable but not loaded? All the exploit needs to do is reach out and trigger the Monolog autoloader, and then include yet another class object that targets the vulnerable class. Impressive.

Dota 2 V8

Community modding of video games is pretty impressive. There’s a long history of clever modders swapping out graphics, or making tweaks to their favorite games. Over the years, many game studios have embraced the modding community, and provided tools and even distribution channels for mods. But there’s a bit of a gotcha with mods — you’re running somebody else’s data and code on your machine. When a developer builds a modding API, and vets mods before distributing them, you might not worry about the malicious mod scenario. But alas, it’s still an issue, this time in Dota 2.

The problem was the included V8 Javascript engine, which was stuck on a version from 2018, with all the problems that implies. Researchers from Avast found four mod files, all custom game modes, that used CVE-2021-38003. The first was an obvious testbed file, but it looks like there were three published mods that actually ran some malicious code. Now, Valve has responded, updating the V8 engine to something more recent, and pointing out that fewer than 200 players were exposed to these potentially malicious mods.

Bits and Bytes

The Netgear router platform had a pretty serious vulnerability in the upnpd daemon, that was patched last November. That’s the service that handles Universal Plug’N’Play requests, and it had a buffer overflow issue. Researchers at HDW Sec managed to demonstrate a full pre-auth root RCE with this vulnerability, and it appears to be exploitable over the WAN interface, for extra fun.

The UK, and other countries, have started rolling out a new train ticket system, based around the idea of a Aztec barcode you display on a mobile screen. And this made [eta] wonder, what data does that image actually contain? The answer, after chasing many digital rabbits, was quite a bit actually.

And finally, there’s yet another trove of 16th century correspondence that’s been analyzed and untangled. This time around, it’s letters written by Mary, Queen of Scotts. There was a cipher used to obscure the letters, and while it was finally broken, it was surprisingly challenging to do so. These letters also used letter locking, where the paper itself was cut and folded to make letter nearly impossible to open without tearing. There’s an interesting parallel to modern encryption and verification there. While everything is new, some things also never change.