[Cryptography] Bug in Signal - and what it says about programming

Jerry Leichter leichter at lrw.com
Thu Sep 15 18:48:14 EDT 2016


http://arstechnica.com/security/2016/09/signal-fixes-bug-that-let-attackers-tamper-with-encrypted-messages/ (which has links to the actual release) describes a few recently-reported bugs in the Android version of Signal.  They actually include the vulnerable line of code:

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

remainingData will be used to bound the data to be covered by the Mac.  The problem here is that file.length() is a long.  If you have an attachment whose length is greater than will fit in an int, only part of it will be MAC'ed, so an attacker can append stuff to it.

This is Java code.  Had the programmer written:

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

Java would have issued a truncation warning because 64-bit value was being assigned to a 32-bit value.  But that little cast to int silently discards the high 32 bits of the length; there's now nothing to worry about.

The guys who found the problem actually compliment Signal:  These are the first reported security issues.  Over all, it's held up remarkably well.  But even so, and even in a "safe" language like Java ... there are sharp edges, and it's all too easy to get cut.

Then again:  One wonders how this cast came to be there.  Did the programmer write it without the cast, see the warning, somehow decide it was unjustified, and added the cast to shut the compiler up?  (That should not have been allowed without a careful examination of the affected code.  Code changes to "shut the compiler up" are almost always a bad idea.)  Did the programmer just have some incorrect understanding of constraints on the files involved and thought that, even though the value was stored in a long, it would always fit in an int.  Or - and one can never dismiss such questions - was this a really subtle, hard to find, hole slipped into the software?  Even if a review caught it ... it would be easy enough to explain away, so the risk to some nominal attacker would be small.

                                                        -- Jerry



More information about the cryptography mailing list