HOW A TINY GIF CAN TAKE OVER YOUR IPHONE? CVE-2017-2416
March 01, 2017
HOW A TINY GIF CAN TAKE OVER YOUR IPHONE? CVE-2017-2416
Hackers have many tricks up their sleeves, from large exploits to small – and Flanker017, a security researcher from China has recently discovered one of the smallest – a remote code execution triggered by malformed GIF that allows a hacker to install a malware “on the sly.” The vulnerability means that, once again, users are subject to the whims of programmers – or a lack of understanding of the nuances of native programming – who fail/are unable to follow the rules for writing secure programs, as prescribed by the makers of operating systems,
Here below is a perfect example of what results when programmers fail to follow those rules.
The implications of this failure or vulnerability is that millions of Apple Mac, iPhone and iPad users, are at risk as exploiting this vulnerability may lead to remote code execution, hence complete takeover.
GIF98a image specification
In order to understand the source of this vulnerability, let’s review GIF specification. Here is a snippet from page number 8, describing GIF Logical Screen Descriptor.
Gif logical descriptor as described in https://www.w3.org/Graphics/GIF/spec-gif89a.txt
Now let’s check how this descriptor data is represented in a valid GIF such as Votiro’s logo file using 010Editor:
Invalid GIF header [cve-2017-2416-gif-Stykz_Sample2.gif from Flanker017 post]
You can see that the Width and Height are (790 x 472), indeed valid values..
Signed Comparison Vulnerability
The nature of the discovered vulnerability is signed-ness error or type confusion;
A signed-ness error occurs when a signed integer is interpreted as unsigned, or vice-versa.
In twos-complement representation, such conversions cause the sign bit to be interpreted as the most signiﬁcant bit (MSB) or conversely, hence -1 and 2^32−1 are misinterpreted to each other on 32-bit machines.
The program uses a signed comparison to check a value that is later treated as unsigned. This could lead the program to write outside the bounds of allocated memory, which could corrupt data, crash the program, or lead to the execution of malicious code.
Apple iOS 10/macOS 10.12 Vulnerability CVE-2017-2416
Now, as Logical Screen Descriptor dimensions are ushort, which is unsigned 16 bit number, we can specify it as the maximum available unsigned 16 bit number which is 2^16-1=65535.
Valid GIF header
This number is shown below in Width field. As described earlier, while the unsigned representation of 0xffff is 65535, the signed representation is -1.
As described in the original disclosure by flanker017, the vulnerable code that was in in the iOS code is the following:
The code use Width and Height as signed values, means 0x0fff is 65295 or -241. Same goes for 0xffff that is 65535 or -1.
So if [(width * height) > file size * some_factor] the file is flagged as malformed as expected. But as the dimension attributes are used as signed values, we will find that instead of using the dimensions as unsigned values (65535 * 65295) it will multiply those as signed values (-1 * -241) which is definitely smaller than the file size, hence bypassing the safety check. The safety check failure implications is that this malformed image is successfully processed by the vulnerable library, leading to an out of bound read or write, which is actually the remote code execution enabler.
Flanker017 mentioned that one possible mitigation is to check those values before calling the vulnerable code. But this applies only if you’re the vulnerable application developer and does not protect the end users.
Another approach to mitigate those kind of attack is to perform a sanitization of data formats such as images. Using Votiro’s CDR image sanitization module, that supports GIF and many other image formats, the Logical descriptor header is re-built from scratch, eliminating any out-of-specification attributes or values, without requiring any signature or learning.
I’ve used Votiro’s API (api.portal.votiro.com) and uploaded the same specially crafted image to Votiro’s sanitization service. The safe GIF image was retrieved in less than a second and as expected, the faulty values were fixed automatically.
In the 010Editor snippet above, you can find that the re-generated image is still a GIF89a image, but the Logical Screen Descriptor values are set exactly as the actual image dimensions, (350 x 250).
Opening the image actually shows it correctly:
Is there any way a user could avoid being victim of an exploit like this – without being a computer expert? Unlikely; it took experts months or years to discover this vulnerability; who knows how many others are lurking out there?
There really is little users can do to defend themselves from such vulnerabilities; the only real defense is preventing these exploits from reaching systems altogether. In this specific case, it appears that the vulnerability’s existence is due to a lack of knowledge by programmers, who probably had no idea that they were writing code that could be compromised. With the vulnerability established, programmers who were not aware of it need to do some code review in order to patch up their work. But that doesn’t help users with other heretofore unknown vulnerabilities that could still be compromising security. If a vulnerability could be present in a malformed GIF, one could be present anywhere.
Votiro’s CDR technology
CDR or Content Disarm and Reconstruction approach, as designed by Votiro, could be a solution to this and many other security holes that hackers can take advantage of. CDR involves disarming potential exploits by dissecting files (like GIFs) and perform thorough analysis. The system is able to determine the implications of modifications, whether it was written to specifications, whether it needs to be patched, etc. Once analyzed – and vetted for proper form and safety – the file is reconstructed and passed onto the system, keeping all functionality intact, while disarming any malicious, suspicious or potentially harmful objects.
With CDR, the solution moves from detection to prevention; instead of tracking down problems and retroactively solving them, CDR puts the onus on files to “prove” that its code is proper; without that proof, CDR will simply dismiss the file, and it won’t have its opportunity to cause mayhem – or potential mayhem, as in the case listed here. While no reports have come in of hackers using the vulnerability to carry out malware attacks, that could just be because security firms haven’t connected all the dots yet. It may yet come to light that malformed file such as GIFs are a major cybersecurity risk – but for companies that have a CDR system in place, it won’t make a difference how widespread the vulnerability is; they’re safe.