For you listeners of the podcast, you may be aware that I’m doing some research into utilizing document metadata, and the inferences that an attacker can make about the victims overall operating environment. This analysis would allow an attacker to be able to deliver more accurate, targeted attacks against a victim.
One of the tools that I’ve been using is Exiftool, which at it’s core, is an over driven command line front end to all of the options of libexif.
The other day I discovered an advisory about a integer-overflow vulnerability in libexif, the basis to several other tools I’ve been looking at as well. There is no know vulnerability, but from the description, it seems fairly trivial to create a corrupt file to trigger the condition.
Time to proceed my analysis with more caution.
That said, you should always be analyzing unknown, untrusted files in a protected environment. Maybe the environment is an air-gapped machine, or a VM with no networking that you can revert to a known state. This, all in your non-production lab of course.
This also brings up some more points. I relate this to some of the updates to the tools that many of us use every day that introduce vulnerabilities into our environments. Don’t forget that the complexity of the options in a tool (Wireshark for example), or the complexity and implementation if a standard (Exif, 802.11) all contribute to some potential downfall.
That said, I love multi-purpose, extensible tools and standards (Wireshark, Exif and 802.11 included!), but for these complexity reasons, it is important to keep them up to date, and evaluate the implementations.
Sometimes this is easier said than done.
– Larry “haxorthematrix” Pesce