4

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?

Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
5
  • 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
    Commented Dec 4, 2019 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
    Commented Dec 4, 2019 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".
    – user163495
    Commented Dec 4, 2019 at 10:34
  • 1
    @MechMK1 good call!
    – Conor Mancone
    Commented Dec 4, 2019 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
    Commented Dec 4, 2019 at 21:44
1

Merely having malicious in memory won't allow it to execute, something has to either deliberately execute the code or have a bug that causes it to execute the code.

However, passing untrusted data to a generic image processing library is potentially risky.

Many generic image processing libraries support a very wide range of image formats, some of which are very complex. The decoders were often written a long time ago in programming languages like C and C++ where a small mistake can easily turn into a code execution vulnerability.

There are various things that can be done to reduce the risk.

  1. Use decoding libraries for individual image formats that you want to support rather than a library that will try to decode anything.
  2. Use decoding libraries written in "safe by default" programming languages.
  3. Run the image decoding code in some form of sandbox environment, to limit the damage if the image decoder is compromised.
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .