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. Commented Mar 20, 2019 at 9:08
  • Or use a lossless codec to change its format to another one, and back again. Commented Mar 21, 2019 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... Commented Mar 21, 2019 at 19:02
  • Run the converter on an obscure OS, like BeOS, QNX or something like that. Commented Mar 21, 2019 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. Commented Mar 21, 2019 at 20:20

1 Answer 1

Reset to default
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). Commented Jun 13, 2018 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. Commented Jun 13, 2018 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. Commented Jun 13, 2018 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? Commented Jun 14, 2018 at 2:31

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.