igor - Fotolia

How did a Signal app bug let attackers alter encrypted attachments?

The Signal app, used for end-to-end encrypted mobile messaging, contained a bug that allowed data to be added to attachments. Expert Michael Cobb explains the flaw.

Signal, a mobile messaging app that has been recommended by many security professionals, was found to contain a bug that let attackers add random data to attachments in encrypted messages. The vulnerability affects Android users, and has since been fixed in an update. What was the flaw in Signal, and what are the implications for messaging apps that offer end-to-end encryption?

Signal is a private messaging app made by Open Whisper Systems for iPhone and Android devices. All of the messages sent between devices running the app are encrypted end-to-end, and it has been downloaded well over a million times. The Signal app code is also used by the WhatsApp messaging app.

The whole project is open source, so anyone can see how the encryption and the other security mechanisms have been implemented, which is exactly what researchers Jean-Philippe Aumasson and Markus Vervier decided to do. While reviewing the Java code used in the Android version of the Signal app, they found a classic coding error -- an overflow bug. The error occurs in the following line of code:

int remainingData = (int) file.length() - mac.getMacLength();

The "remainingData" variable is a 32-bit signed integer, calculated from the length of the file minus the length of its message authentication code (MAC). However, "file.length()" returns a 64-bit signed integer, and it may be a lot longer than remainingData can handle. As Java is a type-safe language, this doesn't cause a memory corruption condition, but the researchers found that the overflow could be used to subvert the program logic by adding random data equal to 4 GB + 1 byte to an encrypted attachment. Despite this additional data, the value of remainingData will still equal that of the original attachment, as remainingData cannot store all of the data returned by file.length() minus mac.getMacLength().

This flawed line of code is part of the function used to check an attachment's MAC, information used to confirm that it hasn't been changed in transit. The value of remainingData is used to determine the length of the file to be checked, but as it still equals the length on the original attachment, the original MAC remains valid; the attacker's added data is not checked, and the function fails to spot the integrity violation.

Nobody is likely to send a 4 GB file attachment via a mobile phone, but by using compression, the attachment can be greatly reduced in size. If the user has the space on their device to decompress the file, the Signal app does not warn the user that the original encrypted attachment had been tampered with.

Although this is a message authentication bypass vulnerability, the severity of its impact is low, and exploitation isn't straightforward. An attacker would have to compromise or impersonate a Signal server to modify a valid encrypted attachment, steal a signing key for one of the certificates trusted by Android or trick the victim into installing a rogue certificate on their device.

Also, the vulnerability doesn't allow an attacker to decrypt the attachment, only tamper with it. An attacker that gets into a position to use this Signal app attack would be able to do far more damage in other ways, rather than tampering with message attachments in transit and making them too large to open.

Open Whisper Systems issued an update, as the bug could compromise integrity, and was a threat to end-to-end security, particularly if further attacks that leveraged this flaw were developed.

True end-to-end encryption is an essential feature many enterprises now rely on, but apart from a solution that only uses an enterprise's own servers, communications will always travel through a third-party's servers.

Errors in implementation are always a risk, as are rogue employees, but a greater threat is probably that from the users and their devices at each end of any communication. End-to-end encryption does not cover risks at the communication's endpoints, so a message going from A to B is only as secure as the devices on each end. It's a complex challenge that software like the Signal app, the Extensible Messaging and Presence Protocol and the Threema app all aim to solve.

Next Steps

Learn about email alternatives for enterprise employee communication

Find out why OpenPGP uses both symmetric and asymmetric encryption

Discover the effect team messaging apps could have on traditional enterprise communication methods

Dig Deeper on Threats and vulnerabilities