There is another WhatsApp flaw, but instead of malicious GIFs, this time it’s malicious mp4 files. Facebook announced the vulnerability late last week. An update has been released, so first go make sure WhatsApp is updated. Facebook’s advisory is a bit light on the details, simply saying that a “stack-based buffer overflow” was possible as a result of “parsing the elementary stream metadata of an mp4 file”.

Shortly after the bug was announced, a GitHub repository popped up, with a claimed proof-of-concept mp4 file for CVE-2019-11931. (Thanks to [justtransit] on Reddit for the link.) I can’t easily test the PoC file, but we can take a look at it to see what the vulnerability is. What tools do we need to take a look? A hex editor is a good start. I’m using GHex, simply because it was available and easily installed on Fedora.

The other tool we need is some documentation on how the mp4 format is supposed to be formatted. Mp4 has a storied history, descending from Apple’s QuickTime Movie format. Apple’s developer documentation was quite helpful in learning about mp4. I also referenced an obscure archived geocities website to answer a specific question that was unclear on the Apple page.

So what is going on in that PoC mp4 file? An mp4 file is a binary format that contains binary values and UTF text. It’s generally in the format of a four bytes unsigned integer containing the field size, a four byte UTF field containing the human readable tag, and finally the binary data. These size/tag/data sets are referred to as atoms. Some atoms also contain additional header information, like bytes reserved for flags and version information. One of the atoms fields is the meta field, used for carrying metada information. This atom is defined as containing at least three subatoms, hdlr, keys, and ilist. The PoC file appears to have a valid meta atom, at first glance. I assume that WhatsApp’s parser was being fooled in the same way that I was fooled the first time I looked through the file.

In looking for data on mp4 atoms, I discovered a useful tool, AtomicParsley. It’s a bit old, and the source needed some tinkering to get it to compile. The effort was worth it, as running AtomicParsley over the PoC file immediately revealed the attack. Do you see the problem now? The meta atom only totals 117 bytes, but it contains an unnamed atom nearly 7000 bytes long. That unnamed atom is actually the rest of the file. What’s going on, and why isn’t it obvious when looking at the file in the hex editor?

It looks like we have a meta atom that contains an hdlr atom. It makes sense, a four byte length followed by the meta tag, and then a four byte length and the hdlr tag. What isn’t apparent is that the meta atom is defined as having additional header information. The information on the mp4 format that I found states that after the meta string, the file should contain four null bytes, reserved for a version number and three bytes of flags. This shifts the parsing of the meta atom four bytes out of sync, and what appears to be another tag is actually interpreted as a field length. Instead of a length of 33 bytes, that atom has a size of 1.6 GB. This is obviously larger than the file itself, which is why AtomicParsley sees that atom as only being 7095 bytes long.

The vulnerability announcement called the flaw a stack-based buffer overflow. These are generally triggered by writing too much data into a stack variable. Let’s speculate just a bit on what the vulnerability likely looks like. A function responsible for parsing the header of an mp4 file declares a char array that gets stored on the stack, so not using malloc. That array is either set to a length the author considered “long enough”, or may even use a variable length array. Either way, the data is on the stack. It’s likely that this parser does sanity checking on the mp4 file before copying the data into the proper buffers. This sanity check may simply trust the stated length of the meta atom, or it may have been fooled by the almost properly formatted file. Either way, as the data is copied over, the missing four bytes results in the rest of the file being copied into that stack array, which isn’t actually large enough to contain it. The data is copied over whatever is on the stack, overwriting the return address and jumping program execution to wherever an attacker wants.

Once the copy command reaches the end of the file, it probably raises an error and attempts to return from the current function. Since an attacker controls the return address and can write to the stack, that return call can jump directly into the attacker’s code.

It’s unclear if this problem was found and disclosed by [Kasif Dekel], the researcher who uploaded the PoC to GitHub, or if it was being actively used in attacks. Edit: I’ve gotten confirmation on this point. [Kasif Dekel], [Ronen Shustin], and [Kobi Hazak] were actively researching this flaw, but before they finalized their research and disclosed the vulnerability, WhatsApp independently discovered and patched it. The initial reports on this problem are coming from India. If any of you have any additional information on whether this vulnerability has been used in the wild, and particularly information on how to get a live sample of the malicious mp4, please let me know about it!

Nextcry Ransomware on Nextcloud

Remember the NGINX problem we discussed earlier this month? It seems that multiple Nextcloud installs were vulnerable to that attack, and a ransomware attack is actively being carried out against them. Nextcry encrypts the files stored on the Nextcloud instance, and demands just over $200 worth of Bitcoin for decryption. Just a reminder, this isn’t a flaw in Nextcloud itself, but following the official Nextcloud documentation on an NGINX server resulted in a vulnerable system.

Mouseover to Crash

A particularly nasty problem was fixed in Windows 8.1 and 10 this month. A PE (Portable Executable) dll was discovered to crash the Windows kernel when mousing over the file in Explorer. It’s possible this bug could be used to read protected memory, but the nastiness of this problem lies in how hard it is to get rid of the file once downloaded. Attempting to delete the malicious file will also trigger the kernel crash. The folks at Tetrane used this bug as an opportunity to show off their tools, and do a deep dive into the problem and Microsoft’s fix.

The Android Camera Vulnerability

Android uses activities and intents to launch apps, and it’s possible for one app to send an intent to launch another app’s activity. This functionality is useful for many scenarios, but can have unintended consequences, like one app being able to request the camera app take pictures or video.

Imagine you download an app that requests access to your file storage. That gives an app access to all your images, videos, etc. If you’re willing to take that risk, the problem linked above allows that malicious app to take pictures and video, and then access those files. This isn’t a particularly subtle attack: the device will obviously launch the camera app and make the normal shutter sounds as pictures are taken. The researchers at Checkmarx who discovered the problem suggest that a clever attacker would wait till the proximity sensor was activated. Recording a video in that state would likely catch the audio of an ongoing call, as well as being harder for a user to notice, as most phones turn the screen off when the proximity sensor detects a nearby face.

The ArsTechnica article includes an ADB command you can run to test whether your device has been fixed. Its unclear how many devices have received the updates, and its likely that some older devices never will.

Disney Plus and Account Theft

Disney has released their new streaming service, Disney+. It probably shouldn’t be a surprise that a large number of accounts were compromised and sold almost immediately. Many of the Disney+ accounts were pre-paid for two or three years, making them enticing targets.

Disney has stated that they didn’t actually suffer a breach. It’s likely that the accounts were compromised through one of several different methods. Password re-use is the simplest. Another possibility is phishing and ads pointing to fake login pages. Or maybe users logged into an already compromised machine that captured their credentials. In any case, it’s been a bit of a rocky launch for Disney+, likely due in large part to the larger-than-expected number of signups.

Docker CP Escape

Docker has proven itself invaluable as a way to isolate processes on a server. Have a public facing service that you worry could get compromised? Throw it in a Docker container, and even if it gets compromised, the OS is safe… theoretically. Announced on Tuesday, CVE-2019-14271 allows an attacker to trap a Docker image and escape the container into the bare-metal OS.

The central concept of the flaw revolves around administrative commands being run in a chroot environment. Quick refresher, chroot is a Unix command that changes the effective root folder that a command is run in. In many ways, chroot is one of the predecessors to modern Docker-style containerization. Need to fix a non-booting Linux system? Chroot lets you set up an environment where you can run commands on a working machine, but using the target root filesystem.

The docker cp command uses chroot to run a helper binary inside a given docker container. The problem occurs when that binary loads the shared libnss library. It’s already running inside a chroot, so it loads the library from the docker container! An attacker could simply replace a container’s libnss library with a malicious version, and the next time docker cp is used to copy a file out of that container, the attacker’s code is running as root outside the container. Docker 19.03.1 fixes the issue, so make sure you’re up to date!