Just answering a call could have been enough to land you in trouble.
Project Zero researcher Natalie Silvanovich found a buffer overflow that could be triggered by data transmitted as part of the audio and video stream during a call.
WhatsApp, along with many other online calling apps, uses RTP, short for Real Time Protocol, for transmitting voice and video.
RTP was designed to be efficient – for example, it uses UDP instead of TCP, so that data arrives faster but less reliably. (UDP packets aren’t checked to see if they made it to the other end, and can arrive in a mixed-up order; TCP packets are verified and delivered in the order they were sent, which means more network overhead.)
If you lose some data packets from an app you are downloading, the entire download will be corrupted and useless; if you drop occasional voice packets, you’ll just have some inaudible moments in the call.
Unfortunately, RTP also squeezes its data into a binary packet format that needs careful unravelling at the other end to work out what sort of data was sent, how to deconstruct it, and how much data to expect.
Errors and miscalculations when unravelling packed binary data – what the jargon often calls parsing, as it were a tricky Latin translation, which in some ways it is – can easily lead to data being moved around incorrectly in memory, for example by trying to fit 24 bytes into a space intended for just 16.
That sort of bug is known as a buffer overflow, and if the extra bytes trample on data that will later be relied on somewhere else in the software, you end up with a potential compromise of security.
As a result, WhatsApp – and, indeed, any app that routinely accepts and acts on data from unknown and untrusted sources – is at particular risk if there are bugs in the core code that processes data received from outside.
The good news is that the bug was responsibly reported at the end of August 2018, subject to Google’s 90-day disclosure policy, and patched well within the 90-day limit.
Google’s disclosure policy means that the company will deliberately tell the world how the bug works after 90 days, and as a result perhaps even reveal exactly how to abuse the bug for criminal purposes, whether you’ve patched it or not. This strict 90-day rule isn’t popular with everyone, but the theory is that reputable software vendors ought to be able to fix holes in 90 days and therefore won’t find this a problem. In contrast, the 90-day deadline is handy to force companies with a habit of sweeping bugs under the carpet to start taking security seriously.
The bad news – and we hope it’s just a typo or a poor choice of words in this case – is that Google unsealed the bug details before the 90 days were up because it thought a patch was readily available.
In the comment announcing the details of the bug, Silvanovich says, “This issue was fixed on September 28 in the Android client and on October 3 in the iPhone client.”
The most recent version on Google Play is dated 8 October 2018, well after the fixed-by date given by Google, but the most recent iOS WhatsApp software we can find [at 2018-10-10T12:00Z] is version 2.18.93, dated 1 October 2018.
So we’re assuming that Silvanovich’s comment means, “By 3 October 2018 this bug was known to have been fixed in the official WhatsApp client,” but her text could be interpreted to mean, “Any version dated before 3 October 2018 isn’t patched yet.”
What to do?
Whatever the case, this is a patch you definitely want, so make sure your Android or iOS apps really are updating properly.
On Android, open the Google Play app, tap the hamburger icon (three lines at top left) and look on the UPDATES tab for new versions you haven’t installed yet.
On iOS, open the App Store app and tap the Updates icon at the bottom of the screen – if you have outstanding updates they’ll be obvious.
We suggest checking back in a week or so, by which time there will probably have been another WhatsApp update anyway, whereupon you can be sure you’re immune to this bug, no matter how you choose to read Google’s ambiguous words now.
Follow @NakedSecurity
Follow @duckblog
by
Paul Ducklin