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.
