For example, if someone uploads a malicious image on website like Instagram or Facebook, and then hundreds of people viewed this image, wouldn't that be an easy way to infect the devices of hundreds or thousands of people? If so, why do people view tens or hundreds of images without being afraid of getting their device infected?

  • Note that in a recent example of such a vulnerability, "the good news is that so far Google has heard no reports wherein the vulnerability had been used to target Android users." Perhaps we've just been lucky in addressing such bugs before PoC code was known.
    – gowenfawr
    Commented Aug 29, 2020 at 16:58

2 Answers 2


While hiding malware in an image is possible, it's not as simple as it may first seem, and there's a lot of nuance in terms of what "hiding malware in an image" could actually mean, and what the behaviour of that image is in practice.

First things first, let's talk about steganography. It's the practice of hiding information inside other information. For example, you might agree with a friend that a particular codeword in a phonecall (e.g. "roast beef") means you're on a bad date and need an excuse to leave. That's a very basic form of steganography. The codeword seems innocuous to an outsider - "did you remember to put the roast beef in the fridge?" is not a suspicious question - but there is hidden meaning to those that are aware of it.

Steganography can be applied to digital media, too. An image might have a fine line of pixels at the very edge that encode a series of bytes that contain a message. A person casually viewing the file would see an image, but probably not notice the single line of pixels at the edge, and even if they did they might not think anything of it. This approach is quite limiting, though. Lossy compression formats (e.g. JPEG, GIF) would not produce the exact same pixels as were put into the compressor, so they can't be used with this simple technique - you need lossless storage like BMP or PNG. It's also limited to a small amount of data - add too much, and the weird line of pixels becomes obviously visible. An approach that increases the amount of data that can be stored is to replace the least significant bit of each red, green, and blue value, for every pixel, with one bit of the secret message. This is visually imperceptible to the human eye, but again it breaks if you save the image as a JPEG or GIF, or resize or process the image in any way.

There are more complicated approaches that surivive being encoded as a JPEG, and there are other techniques such as storing secret messages in metadata (e.g. EXIF tags in a JPEG, ID3 tags in an MP3, or hidden streams in a video container) that would only generally be noticed by someone explicitly looking for them.

A problem with sharing these steganographic media files via social media networks is that they don't leave your file alone when you upload it. They resize it, recompress it, strip metadata off it (largely for privacy and space saving reasons - there's no need to store random metadata, and geolocation tagged photos can leak your exact location), and may even crop or colour-correct the image. It makes sharing these kinds of files on those platforms very difficult.

You might notice something here, though: these are just regular image or video files. They don't do anything magic when you open them. They're just a regular media file, with some cleverly manipulated pixels or metadata, and you have to know that there's some secret thing in there, know how that secret was encoded, and use some tool to extract the message. They don't magically infect you with malware when you open them.

You're clearly aware of the concept that opening benign non-executable file formats might result in being infected with malware, but how does that actually work? The answer is almost always one of two things: embedded macros, or exploitation of a software vulnerability.

I'll cover embedded macros very quickly. In many office document formats (e.g. Word, Excel) there's a feature that lets you store scripts inside a document. These are called macros. They're often used to add more complex behaviour to a document, e.g. having a button in a spreadsheet that pops up some question boxes for you to fill out in order to generate a report. These macros can also be written in a way that is malicious, and modern versions of office software normally disable them by default when you load the document. You have to manually click "yes, enable macros, I'm sure this document is safe" in order to run them. Most malicious documents try to trick you into clicking that button. One example might be that you receive an email with the subject "[Confidential] Department Salary Increases", with an Excel spreadsheet attached. You open it, and the document looks official, appears to be some sort of list of employees and new salaries for the next financial year, and it even has your company logo in it, but every cell with names or salary amounts says "security protected content. enable macros to view". If you approve macros it drops a malicious executable onto your computer and runs it.

This trick doesn't apply to JPEGs or PNGs or MP3s or AVIs. They don't have macros. So how might you get infected by a malicious image or audio/video file? First things first, let's ignore the case where someone named the file private_snapchat_23.jpg.exe and it's not actually an image file. It's obvious how that one is malicious, and you can't just upload that to a social media site anyway - it won't be recognised as an image at all.

Malicious media files like this rely on vulnerabilities in the software the reads the file. The exact details of how vulnerabilities and exploits work constitute and entire field of study, with more than enough complexity to fill hundreds of books, so I'll skip all but the very basics.

It is not unfair to say that computers border on being maliciously compliant. They will do exactly what you tell them to, ignoring any subtlety or nuance in your intentions, and almost always without any warning that what you want to do is not in your best interests. If you say "pick up that brush, brush the cat, then put it in the dishwasher", it'll put your cat in the dishwasher. The problem is that software developers are human, and translating between what a human wants and what a computer needs to be told in order to achieve that goal is a very hard job. Even if all the tooling is perfect (which it isn't) humans make mistakes all the time. They write buggy code. Sometimes these mistakes mean that the behaviour of the computer can be altered by the data it is working on, in a way that was unintended by the developer. When these bugs can be abused in order to bypass security expectations, we call them vulnerabilities.

As a brief technical example, let's talk about buffer overflows.

Let's say you allocate a certain block of memory, 50 bytes long, to store a particular field that you're reading from a file. We call this a buffer. The file format specification says the field shouldn't ever be more than 32 bytes long, so the developer figures that a buffer of 50 bytes is a nice round number and more than enough space to store the field data. The data in the file encodes this particular field as a single byte denoting the length of the field, followed by the contents of that field.

Here's an example of what that field might look like in the file, in bytes:

0d 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 21 

The first byte, with a hexadecimal value of 0d (13 in decimal) specifies that the field is 13 bytes long. The remainder of the field is the data, which decodes to the ASCII string "Hello, world!".

The program parses this field by reading the length value, then copying that number of bytes into the buffer. But the developer made a mistake: they forgot to validate that the length value is 32 bytes or less, as per the specification. This also means they didn't validate that the length field is smaller than the buffer size. Normally, this isn't a problem, because files adhere to the specification and don't try to store any field bigger than 32 bytes. But if someone makes a file that purposefully violates the specification, they can make the program crash.

As an example, the field data might look like this:

64 54 68 65 20 71 75 69 63 6b 20 62 72 6f 77 6e 20 66 6f 78 20 6a 75 6d 70 73 20 6f 76 65 72 20 74 68 65 20 6c 61 7a 79 20 64 6f 67 2c 20 61 6e 64 20 74 68 65 20 75 6e 68 61 70 70 79 20 64 65 76 65 6c 6f 70 65 72 20 68 61 73 20 61 20 74 65 72 72 69 62 6c 65 20 64 61 79 2e 20 57 68 6f 6f 70 73 20 3a 28 

The first byte denotes the length of the data. 0x64 is 100 bytes - twice the buffer size! The program doesn't validate that this size is ok, so it just copies 100 bytes into a 50 byte buffer. The data overflows the buffer (we call this a buffer overflow) into adjacent memory. That memory could store anything! It might be a buffer for another field, it might be where the program stores some variables, or it could be where the program stores state information about where it needs to jump to after this bit of code has finished running. Writing garbage data to this memory is called memory corruption, and it usually results in a crash.

However, you can often do more than just crash the program. You can look at how the program works internally, reverse engineer the assembly instructions that are being run in the vulnerable portion of code, look at the memory layout, and see what parts of memory you can corrupt. From this you may be able to specifically craft the data you put in the file in order to carefully overwrite program memory in order to run instructions of your choosing, instead of the normal program behaviour. This is called an exploit. The topic of vulnerability research and exploit development is vast, as previously mentioned, and generally requires a fairly deep understanding of how computer programs work and what security mechanisms are in place to mitigate exploit techniques, so I won't go into full detail here.

Note: It's worth me pointing out that the above is just an example. In reality vulnerabilities can take a lot of different forms, and they're not always reliant on buffer overflows or memory corruption. Again, the specific details are broad and complex enough to be worthy of multiple books, not half a paragraph in a StackExchange answer.

One thing that is critical here is that an exploit targets one vulnerability in one specific piece of code on one platform. It isn't universal. If you write an exploit for a vulnerability in the part of Windows Media Player that reads MP4 files, you can't just take that malicious MP4 file and use it against VLC, or on SMPlayer on Linux, or on your phone's video player app. Even if a vulnerability is found in a cross-platform library that is used by image viewers or video players on Windows, Linux, MacOS, iOS, and Android, you generally need to write a separate exploit (sometimes called a payload) for each of those platforms due to the different operating systems having different APIs, memory layouts, exploit protections, etc., not to mention that some of them are running on entirely different CPU architectures (e.g. x86-64 for Windows vs. ARM on an iOS or Android device). On top of that, bypassing exploit protections (particularly sandboxing in modern browsers) is quite difficult, and usually requires multiple vulnerabilities to be chained together. On mobile platforms it may be even harder. Even then, the exploit will likely only work against a few specific versions of the software, and one or two versions of the operating system. It can take weeks or even months of hard work by a talented exploit developer, along with a bunch of luck, in order to produce a stable exploit. This is after they spend a very long time reverse engineering various bits of software and reading source code in order to even find a usable vulnerability in the first place.

Now think back to earlier, when I talked about the problem of sharing steganographic images over social media. If they re-encode the image, your specially crafted bytes almost certainly go away. This means that even if you found a vulnerability in an image decoding library used by a large number of operating systems and devices (e.g. one used in Chrome or Firefox for displaying images), you'd still need to write separate exploits for each OS and browser, and find sandbox bypass vulnerabilities in order to actually do anything useful, and write exploits for those (which again need to be targeted to the browser and OS and CPU architecture), you'd still probably not be able to share it by social media because the carefully crafted file would get mangled by the server during re-encoding.

On top of all of this, the bad guys run into an economic problem: they almost always have to expend a lot of time and effort writing a functioning exploit, but a whitehat can find the same bug and spend just a few hours writing up a report to a vendor to get the vulnerability patched. And, even if they do successfully deploy the exploit against victims through some popular platform, it doesn't take long before their exploit payload is detected by intrusion detection systems, and their malware (exploits are generally limited in capability themselves, are usually used to download and run a larger program that can then provide more comprehensive capabilities to the attacker) is detected by anti-malware programs. It's often cheaper and easier to just use simple phishing attacks with office documents containing macros than it is to try to discover and practically exploit these types of vulnerabilities.


If malware can be attached to an image file, then why aren't images a common attack vector?

Lets start with your basic premise,that "malwares" being shellcode/exe can be for the lack of better word "attached" with an image,i dont know attach is the right term,but you cannot execute exe/shellcode by attaching anything to an image file.

So can image somehow execute code on a system which furthers downloads and infects a system?

Although not impossible,you will have to find a very specific vulnerability in the image viewer software that somehow ends up executing the commands an attacker wants by reading the malicious command embeded in the image.

Now lets jump to

For example, if someone uploads a malicious image on website like Instagram or Facebook, and then hundreds of people viewed this image, wouldn't that be an easy way to infect the devices of hundreds or thousands of people?

Again,not impossible BUT and here is a big but,you will have to chain multiple zero days to accomplish this task. Well for starters social media sites,strip all metadata and even performs lossy/losless compression on the image,so you will somehow have to smuggle your data in such a way as the image doesnt lose the bit you want. Then the browser in which the image is viewed,you will have to find a zero day in that,such that malicious command is executed and even after that you will have to evade the sandbox and other protection that browsers apply.If you can perform such an attack,you would probably be smart enough not to and make bank selling it.

You must log in to answer this question.

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