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.