Posted by John Kozyrakis on June 18, 2015
The Samsung Galaxy phone hack was not caused by “one bug.” It was due to a chain of several failures, which makes it difficult to say who is at fault and how the Samsung hack could have been avoided. Don’t jump to conclusions!
Issue 1: Samsung uses a white-label version of the popular SwiftKey 3rd-party keyboard app as the default keyboard in recent Android devices. In order to do that, it repackages it and installs it into the system partition. This gives the keyboard app “system” privileges.
Issue 2: Android’s ZIP library is vulnerable to a directory traversal vulnerability, similar to what described at CERT’s Secure Coding Guidelines IDS04-J. Many researchers believe that other platforms, like iOS, suffer from the same issue, but I have not personally confirmed this. How does this work? An attacker constructs a malicious zip file in which the name of an included file contains a directory traversal. The extraction code follows the traversal and places the file in a directory that the app developer wouldn’t expect.
Issue 3: SwiftKey downloads certain zip files over HTTP. These are typically files that contain extra languages. It must be noted that these are application assets, not executable code. Just as most apps download image files over HTTP, this app downloads some ZIP files with text in them. There is no vulnerable update mechanism in place. SwiftKey would probably not find a flaw during code audits, penetration tests or design reviews because downloading an asset over HTTP is not normally a flaw.
The combination of all three issues allowed the researcher to achieve remote code execution. He did this by performing a man-in-the-middle attack on the cleartext traffic [due to Issue 3] and replacing the downloaded ZIP with a malicious one. Upon extraction, this new ZIP overwrote an executable file [due to Issue 2], enabling the execution of malicious code included in the ZIP. The location of the overwritten file had filesystem permissions that prevented access to normal users, but this was possible due to the keyboard app having system privileges [Issue 1].
What is interesting is that normal, non-system apps are vulnerable to Element 2 and Element 3.
An attacker can replace a downloaded ZIP file with a malicious one and overwrite any file a normal application has access to.
The impact of this type of attack is related to the chosen target. Here are a few examples:
Samsung could fix this via a SELinux policy update, pushed to devices urgently. Read Samsung’s response to the issue.
If you are a device manufacturer like Samsung, a device integrator, or a network carrier and you create your own system images, you should be very careful.
You’ll need to add processes to your Software Development Life Cycle (SDLC) that minimize a device’s attack surface—for example, letting as few apps as possible to be signed using the system certificate. There are alternative options that you could use to handle apps like SwiftKey. You could fine-tune the SELinux policy of the device so that individual apps are further restricted, even if they hold elevated privileges. This would limit the attack’s impact severely. For the few apps that need to be system-privileged, you should implement extensive security audits as well.
If you are the Android Security team, you should probably work to fix the ZIP extraction–file traversal issue. Same goes for Apple, if vulnerable.
Developers like SwiftKey should probably not attempt to download ZIP files over HTTP, even if they are just static asset files. Developers should seriously consider converting all traffic to HTTPS. Both Android and iOS platforms are starting to offer robust infrastructure that incentivizes developers into switching to secure communications.
Gaining system remote code execution through third-party apps included in the system images is not new or exciting as a concept. At Synopsys, we have repeatedly found RCE vulnerabilities in almost the exact same way during client assessments over the past two years.