5

I've sometimes heard/read that one of the ways to deal with embedded exploits (malware code built into the image encoding itself) is adding random noise to an image file, or resizing the image. Are any of these methods in fact helpful?

As a very simple (non-exhaustive) example, something like this where javascript is injected into the image encoding section of a gif to execute an xss attack.

I've already checked this security.se question which has useful info but not exactly what I'm asking here.

Improve this question
5
  • A possible solution might be to process/view the image in a sandboxed environment. – Marcel Mar 20 '19 at 9:08
  • Or use a lossless codec to change its format to another one, and back again. – ThoriumBR Mar 21 '19 at 18:55
  • @ThoriumBR That would open up the decoder/encoder to exploitation. If you want to convert an image as PNG->BMP->PNG because you're afraid of a vulnerability in your viewer's copy of libpng, you'll be screwing yourself by passing the same exploit through a conversion program that uses the exact same libpng. It could be possible to do this securely if you convert PNG->PPM->PNG where the conversion process uses a tight syscall sandbox and sets resource limits, and only passes data over shared memory or pipes... – forest Mar 21 '19 at 19:02
  • Run the converter on an obscure OS, like BeOS, QNX or something like that. – ThoriumBR Mar 21 '19 at 19:04
  • @ThoriumBR Huh? First of all, that's security through obscurity and is a bad thing (and QNX isn't obscure anyway). Second of all, even the most obscure OS uses the same vulnerable image decoder libraries as everyone else. If you are using an image viewer on BeOS, it's going to be using libpng for PNG files. – forest Mar 21 '19 at 20:20
2

It depends. The specific example you gave is for an XSS exploit, which is not an exploit of image viewers or decoders. Modifying such an image may destroy the malicious code, depending on the kind of exploit. If the image is corrupt such that it will exploit an image viewer, editing the image in any way (including resizing it) will very likely pass it through the same vulnerable decoder (e.g. libpng) as the one used by an image viewer. Consider this simplified view of how an image editor works:

  1. A source image is passed through a decoder which converts it into a pixel map.

  2. Any modifications to the image are made to this raw pixel map, in memory.

  3. The pixel map is compressed and converted into a standard image format.

Now compare this to how an image viewer works:

  1. A source image is passed through a decoder which converts it into a pixel map.

  2. The pixel map is displayed directly on the screen.

The first step in both instances are the same. Unfortunately, this step is where the vulnerable image decoding library is affected. In many cases, modifying an image is actually worse because the decoders are often more complex in order to support a wider variety of obscure formats and features.

Improve this answer
4
  • It's not quite true that it "will necessarily pass it through the same vulnerable decoder", many formats have multiple decoders available (I know jpeg in particular has quite a few). – AndrolGenhald Jun 13 '18 at 13:26
  • @AndrolGenhald True, but the vast majority of the time, it will use a single decoder on a single platform. E.g. on Linux, imlib2, graphicsmagick, imagemagick, GIMP, Firefox, Eye of Gnome, Gwenview, feh, and mpv (which can display images) all use the same decoder for JPEG. – forest Jun 13 '18 at 13:27
  • Actually JPEG may be the best example where it's currently split, many projects started switching to from libjpeg to libjpeg-turbo, so depending on the software version and build options it may use one or the other. It is a fork, so its entirely possible that a vulnerability would affect both, but it's also possible it wouldn't. In general though I agree, a vulnerability in a popular decoder could be devastating. – AndrolGenhald Jun 13 '18 at 13:38
  • 1
    @AndrolGenhald You're right. My point was that there is very little diversity in the decoders, even if there are a few popular forks. It's not like a libc where you have glibc, dietlibc, uclibc, musl, bionic, Windows whatever they call it, OpenBSD libc, etc. I mean really, who wants to write a decoder for the entire JFIF standard from scratch? – forest Jun 14 '18 at 2:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.