Dealing with the ExifInterface Security Flaw
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
represent a much shallower
bug, and if you are using
ExifInterface, you could switch to another,
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
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
FileDescriptor objects. Those were the reason
I advised developers to move off of the platform’s
ExifInterface only used to work with
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,
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
that supports the Android 7.0 API, for backwards compatibility,
for better integration with
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
would be added to the Android Support library,
so that we have a common reliable implementation that everyone
Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!Tweet