Dealing with the ExifInterface Security Flaw

The ExifInterface in Android, from at least around Android 4.2 onwards, has security flaws in the native JHEAD library that it uses for EXIF parsing. These flaws were uncovered by Tim Strazzere. Patches are available for device manufacturers and custom ROM developers for some versions of Android.

Which means that over a billion people are still screwed. For most Android devices, security updates are mythological creatures, on par with unicorns.

If the class name ExifInterface sounds familiar, that may be because I blogged about it a few months ago.

ExifInterface is the Java class responsible for parsing EXIF headers out of image files, mostly JPEGs. You might be using it to get orientation information about a photo, or get at the geo-tagged location, and so on.

Many Android security bugs are fairly deep in the OS, such that app developers cannot really do much about them (e.g., StageFright). The issues involved with ExifInterface represent a much shallower bug, and if you are using ExifInterface , you could switch to another, bug-free implementation.

The alternative implementations that I linked to in that earlier blog post should be fine, as they are pure-Java solutions, avoiding the buggy JHEAD library.

Or, you might use the patched Android 6.0 version of ExifInterface , where they dumped JHEAD and replaced it with pure Java code.

However, independent of all of this, Android 7.0 updated the API of ExifInterface . The big thing is that they added in constructors that take InputStream and FileDescriptor objects. Those were the reason I advised developers to move off of the platform’s ExifInterface originally, as ExifInterface only used to work with File objects, and you cannot readily get File objects for content from third-party apps, the Storage Access Framework, and so on.

Curiously, the security patches for Android 7.0 patch JHEAD, leaving ExifInterface alone, rather than replacing JHEAD with equivalent Java as they did when fixing the issue on older Android versions. So, we cannot readily use that class version ourselves directly, since we cannot load that JNI library.

What is needed is a pure-Java implementation of ExifInterface that supports the Android 7.0 API, for backwards compatibility, for better integration with content Uri values, and to help developers avoid the buggy platform class on unpatched devices. As I suggested in my earlier blog post, ideally some sort of ExifInterfaceCompat would be added to the Android Support library, so that we have a common reliable implementation that everyone can use.

Learn second-generation Android app development — with Kotlin and the Android Jetpack — through CommonsWare’s Android app development training!

— Sep 08, 2016