5

I have a java web application that accepts base64 image strings from users. These strings are first converted to a byte stream after which the stream is scanned for viruses. After that the file is stored as a resized version of the actual image.

My question is, when the file has been transformed from a base64 string to an in-memory byte stream and it happens to contain a virus, will that virus be able to escape the byte stream and infect the rest of the server? Or can it only do that after the stream has been transformed to a file stored on disk?

11

Neither.

A virus sitting on a disk as a file is harmless. A virus sitting in memory as data is harmless. It can only infect a machine when something tries to execute it or interprets it improperly. This can happen because of user action (tricking someone to download and run a .exe file) or because of application weaknesses which is what you are asking about (e.g. hiding malicious data in a PDF to trigger a vulnerability in a PDF reader and trick the application into executing malicious instructions).

So to pick some examples from your situation:

  1. If your webserver has a RCE vulnerability then malicious data in the request may execute a virus before it even reaches your application (examples)
  2. Improper input handling may allow an attacker to trick your application into executing malicious commands (examples, more examples)
  3. An error in your programming language's stream processing system may allow a malicious payload to execute code (which is so unlikely I don't even have any examples of it)
  4. If the location you store your file on disk is also a location where your application may find and execute code, then an attacker may trick your application into saving a virus and then trick your application into executing it (examples)
  5. If your image processing library has a known vulnerability then a malicious image may be able to execute commands on your server (examples)

However, a virus can't cause trouble simply by being on your server. It has to find a way to execute itself. The only defense is to practice proper application security and keep everything up-to-date.

  • 1
    Upvoted, but I want to mention that image library vulns aren't that uncommon. It's bad enough that I generally recommend doing any image processing in a special-purpose sandbox. Both image format handlers themselves and programs / frameworks that use them (lookin' at you, ImageMagick) have had numerous critical vulns in the last few years. – CBHacking Dec 4 at 4:46
  • @CBHacking having had to patch my servers/applications due to vulnerabilities in ImageMagick, I agree! Mainly I was just having trouble finding the right words. In my head the order of decreasing likelihood is: Application Weaknesses -> Image Upload Problems -> Image Processing Library -> Webserver -> Stream processing. Although maybe I just need a different approach anyway... – Conor Mancone Dec 4 at 10:26
  • 1
    I would not really say "execution" alone is valid, given how you mentioned bugs in image libraries. I would say "execution or interpretation". – MechMK1 Dec 4 at 10:34
  • 1
    @MechMK1 good call! – Conor Mancone Dec 4 at 10:55
  • @MechMK1 "Parsing" is how I'd put it, but yeah. Especially with native code - which most image libraries seem to be - decoding/rendering/editing/whatever on a blob of structured data can be dangerous. There's also deserialization vulns. – CBHacking Dec 4 at 21:44

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.