(false alarm) overflow exploit on 0.25 001900 64bit

[Phoebe-G]

I was looking at a photo taken with an Android phone this morning and it appeared to trigger an overflow exploit after hitting the comment block.

I know 0.25 is an older version, but I was wondering if this is/was a known issue? A quick search seems to indicate that EXIF exploits were pretty popular last year, but the build I am running is the version currently packaged with Arch Linux. I would not be surprised to learn other distros ship that or even older versions.

~ ❯❯❯ exiv2 pr ~/Downloads/test3.jpg                                                                                                                                                         ⏎
File name       : /home/[redacted]/Downloads/test3.jpg
File size       : 4544798 Bytes
MIME type       : image/jpeg
Image size      : 5312 x 2988
Camera make     : samsung
Camera model    : SM-N915G
Image timestamp : 2017:05:19 12:45:36
Image number    : 
Exposure time   : 1/246 s
Aperture        : F2.2
Exposure bias   : 0 EV
Flash           : Fired
Flash bias      : 
Focal length    : 4.8 mm (35 mm equivalent: 31.0 mm)
Subject distance: 
ISO speed       : 40
Exposure mode   : Auto
Metering mode   : Multi-segment
Macro mode      : 
Image quality   : 
Exif Resolution : 5312 x 2988
White balance   : Auto
Thumbnail       : image/jpeg, 14701 Bytes
Copyright       : 
Exif comment    : 
JKJK	:\<§¼^ÞjòïüÌÄÿÿ5"@Ëÿÿ»bÒÿÿ£
                                   ÿÿ¿Û1"!"" "!""p"p!"!" " " " " " "!"1"1" "1"!"!" " " "00 " " " " "!"A"!" """"" " " " " " " " "!"1" """""""""" "0 " ""pA""""""""""0 " " " """"""""""" "`3p	0 """""""" " " " "p		0 "!" " " " " " " " " "000""!"1" " " " "0 " " " " """ " "1"Q3 " " " "0 "00000 "001"`3`3af " " "0000A"0A"A"A"`3`3`3`3af " " "A"Q3Q3A"1"Q3Q3`3af`3`3`3`3 "	`ß}l¯ê¬B×{wGðöy4ñRlkkkkkkFAFA|P0pFAFAeÿ/ª ®dåaÿ/qj=¸%ÿ/ý®oÛÙ$ÿ/ېuê$ÿ/9-|Y1"ÿ/"pA"`3`3afafafafqfqfafQ3afafafafSñT
                                                                            ®¾ÿ/ûC/ ÿ/Ût(|5½"ÿ/}Òu*­#ÿ/Q¦Üoì_#ÿ/À1jËa#ÿ/õRjÀ7"ÿ/õRjÀ7"ÿ/õRjÀ7"ÿ/õRFAFA.
                                                                                                                                                      H
                                                                                                                                                       |Z-ìjH
                                                                                                                                                             FZpìè3ÜQyjçpÿFAFA®®®®FýC
                                                                                                                                                                                     JÊ J	[èèò.8¨	8W[Õ2$J
SV]*:^[[?1;2c²9
^[[?1;2cþÿÿÿ (ö]ò¼¥¯
òvsùÿÿÿ|
        4
         J
          7	
                ¡kP02596487H16USHA00VM51FFCFDDF80ssois63AH05 63AH05 63AH05 0 2 3


^[[?1;2c^[[?1;2c^[[?1;2c^[[?1;2c^[[?1;2c^[[?1;2c^[[?1;2c^[[?1;2c^[[?1;2c%                                                                                                                      ~ ❯❯❯ 1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c
cd: no such entry in dir stack
zsh: command not found: 2c1
zsh: command not found: 2c1
zsh: command not found: 2c1
zsh: command not found: 2c1
zsh: command not found: 2c1
zsh: command not found: 2c1
zsh: command not found: 2c1
zsh: command not found: 2c1
zsh: command not found: 2c1
zsh: command not found: 2c1
zsh: command not found: 2c

I guess this is mostly gibberish, the payload wasn't crafted for this platform, luckily. But to my eyes this looks like it could be used to successfully perform an exploit.

Building from the github source, I don't see anything anywhere near as scary (just an EXIF comment full of "junk" characters) which makes me wonder whether there was a known fix since 0.25?

[clanmills]

Can you attach your test file and I will investigate. This issue doesn't sound familiar, however there are many changes in v0.26.

[Phoebe-G]

I've shoved it in an archive to avoid anyone accidentally getting infected, assuming I'm correct that this is malware.

I suspect the payload (assuming this isn't just some incredibly weird quirk of random chance) is for Android. Is exiv2 is included in Android? It seems possible that it's targeted at some other lib and exiv just happens to choke on it.

background news from last year: securityaffairs.co/wordpress/51043/mobile-2/android-cve-2016-3862-flaw.html

[clanmills]

I've never built exiv2 for Android.

I've run the Exiv2 command (both v0.25 and v0.26) on your file on MacOS-X and nothing unusual happened. The image does contain a user comment with binary data:

557 rmills@rmillsmbp:~/gnu/git/exiv2 $ exiv2 -pa --binary --grep comment/i ~/Downloads/test3.jpg
Exif.Photo.UserComment                       Undefined 2296  
JKJK	:\<??^??j???????5"@????b????
.... stuff deleted ...
                ??kP02596487H16USHA00VM51FFCFDDF80ssois63AH05 63AH05 63AH05 0 2 3

558 rmills@rmillsmbp:~/gnu/git/exiv2 $ 

However I don't feel exiv2 is doing anything harmful.

If this is a security issue being exposed by Exiv2, I assure you of my cooperation to address and fix this matter.

Perhaps you can explain your use case again. Are you using Exiv2 on a desktop to inspect the metadata from a image taken with an Android device? So, we're discussing Exiv2 on a Linux Desktop and not discussing a build of Exiv2 on Android. Is that right?

[Phoebe-G]

Perhaps you can explain your use case again. Are you using Exiv2 on a desktop to inspect the metadata from a image taken with an Android device? So, we're discussing Exiv2 on a Linux Desktop and not discussing a build of Exiv2 on Android. Is that right?

Correct. I'm using Exiv2 on Arch Linux (on my laptop) to look at this photo taken with my phone.

My suspicion is that some sort of malware on the phone is infecting the EXIF data with an exploit, with the hope (on the malware author's part) that the image will be uploaded to web services running software vulnerable to EXIF overflow. If you do a search for EXIF overflow it seems that there is precedent for this kind of attack.

I'm not sure what I should do with this. I'm not a security researcher so it's a bit confusing. After re-running the command I'm not seeing the same failed directory change error from the first log which is frustrating.

Exiv2 isn't necessarily the intended target and 0.26 doesn't do anything weird when parsing these same images, so I'm not sure there's anything for you to do here. Hopefully it's nothing.

I will flag the Exiv2 package on Arch Linux as out of date and probably remove that image from my previous comment later now that you have a copy.

[clanmills]

Thanks for marking Exiv2 on Arch as "out of date". I'm going to have a look at this on Linux (Ubuntu 16.04 and Fedora). If necessary, I'll install Arch Linux on a VM.

Exiv2 parses the UserComment as binary data. It doesn't assume it's a nul terminated ascii string. And, while the length of the comment at 2296 bytes is quite long, however it is not causing an overflow. The length field is sane and not reaching outside the EXIF segment which is embedded in the JPG. So, I feel calm and relaxed.

I will investigate your file on both v0.25 and v0.26 on Linux as this subject deserves careful attention. Thank You for the file, I think you can safely remove references from this thread.

[Phoebe-G]

Looks like someone beat me to it on flagging the package. It's been flagged for about a month.

I think this image is harmless on Exiv2. I've just carefully re-read the log that I pasted in my first comment.

It appears that when Exiv2 printed the contents of the comment field, a bunch of "stuff" was dumped to the terminal, some of that "stuff" ended up inserted after my prompt. I must have then hit enter myself (!) while my prompt looked like this: ~ ❯❯❯ 1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c1;2c

If I just type 1 into zsh I get the cd: no such entry in dir stack message. And of course all those 2c1 are each being sent as a separate command. By me. Because I hit enter.

I guess it's still undesirable that Exiv2 generated* the erroneous "stuff," but as mentioned earlier it behaves sanely on a more recent build.

As for why photos taken with my camera have such weird comments.. maybe it is malware, or maybe it's Samsung being "helpful" somehow.

Thanks for taking a look over things.

*Edit: not generated, but perhaps just faithfully printed what was already there?

[Phoebe-G]

Google search for kP02596487H16USHA00VM51FFCFDDF80ssois63AH05 63AH05 63AH05 0 2 3 (and substrings of it) show many results in, eg. wikipedia's photo metadata viewer. All taken with Samsung devices.

Edit: a search for "samsung EXIF user comment" seems to show this is a common, and old, recurring "bug" with Samsung cameras. Wonder what they're putting in there.

[Phoebe-G]

I went back to the phone and tagged one of the photos with a bunch of text. The output from Exiv2 is slightly different. So my theory is that they're storing that user-added metadata in the User Comment field.

False alarm. Probably. Doubt there's any need to waste more time on it. :)

Thank you again.

[clanmills]

Here's a little forensic test:

$ exiv2 -Pv --grep Comment --binary ~/Downloads/test3.jpg  | od -a -
0000000   c   h   a   r   s   e   t   =   "   A   s   c   i   i   "  sp
0000020  nl nul nul nul   J   K   J   K dc2  ht   :   \   < enq soh nul
0000040   ' eot soh nul   < nul nul nul   ^   ^ soh nul nul nul soh nul
0000060  so   j soh nul soh nul nul nul nul   r bel nul nul nul nul nul
0000100 nul nul nul nul nul syn nul nul   o   | soh nul nul nul soh nul
0000120 esc   w soh nul bel   L soh nul   D dc1 del del   5   " nul nul
...
0004260   k soh nul nul nul soh nul nul   P   0   2   5   9   6   4   8
0004300   7   H   1   6   U   S   H   A   0   0   V   M   5   1   F   F
0004320   C   F   D   D   F   8   0 nul   s   s   o   i   s   6   3   A
0004340   H   0   5  sp   6   3   A   H   0   5  sp   6   3   A   H   0
0004360   5  sp   0  sp   2  sp   3  nl nul nul nul nul nul nul nul nul
0004400  nl
0004401

Some of this (at the start and finish) looks sane. However it's mostly binary stuff. Samsung should be store their binary sauce in the MakerNote and not in UserComment.

I'm going to close this.