1

let say an application allows only images to be uploaded

now yes images can contain a virus (source) However If the application is serving only resized image (and never the original upload) can the resized/reprocessed version contain a virus?

Resize of image is done via a Imagemagick (from within ActiveStorage Ruby on Rails)

update: yes, I'm fully aware antivirus do exist and it's a good practice that the app should scan uploaded files for viruses. I'm asking if the described scenario is possible purely for research purpose or if more experienced collegues from security world have seen this issue in practice

equivalent8
  • 13,754
  • 8
  • 81
  • 109
  • one note: it seems like it's the Metadata not the image itself that contains the virus, so I wonder if imagemagick trim the metadata when reprocessing https://stackoverflow.com/a/9675978/473040 – equivalent8 Dec 06 '22 at 12:01
  • You link to bullguard is fearmongering bullsh*t. Yes you can put code in metadata, but it's another thing to have this code executed. You would have to exploit a very nasty bug in a specific version of an application/library, and this would likely not last too long before it's detected/patched. And the first victim of the virus would be your resizing app, so if you are afraid of this you should have a virus scanner upstream. – xenoid Dec 06 '22 at 16:43
  • @xenoid Thank you for your comment. But I'm afraid it's bit off topic. Question is whether the scenario described is possible (can resized image serve the original image virus?). I agree with your argument that virus scanner can detect a virus and it's definitely good practice to have it. – equivalent8 Dec 06 '22 at 21:54

1 Answers1

1

Nothing is ever impossible I'm afraid, but this one would be very hard to pull off.

To have a virus in the resized image, the attacker would have to make its virus in a way that is:

  • Innofensive gibberish when uploaded, but
  • Materialized as the actual virus by the resizing algorithm.

So given the attacker has the choice of resizing algorithm and the final dimensions of the image, he would need to:

  1. Create a virus or attack vector that targets a vulnerability in an unsuspecting client (like a buffer overflow in a popular web browser)
  2. Run the virus in some "reverse resizing algorithm" and embeed the results in a way that will trigger the vulnerability after the image resize (step 4 below)
  3. Upload the rigged, but still innofensive image
  4. Let the server resize the image to make the virus designed at step 1 "appear" in the image
  5. Wait for an unsuspecting user to download the resized image, triggering the attack (exploit the buffer overflow, in this example)

If the attacker can't pick the algorithm or size, he can certainly run some tests and find out the runtime characteristics of the server, but it will make writing the "reverse resizing algorihtm" of step 2 harder and custom, increasing the (already high) cost of this attack.

Top of my head, adding a random steganographic marker to either (or both) images would send the cost and complexity of this attack out of the ball park.

ixe013
  • 9,559
  • 3
  • 46
  • 77