The novel Daemon is frequently praised for being realistic in its portrayal rather than just mashing buzzwords.

However, this struck me as unrealistic:

Gragg's e-mail contained a poisoned JPEG of the brokerage logo. JPEGs were compressed image files. When the user viewed the e-mail, the operating system ran a decompression algorithm to render the graphic on-screen; it was this decompression algorithm that executed Gragg's malicious script and let him slip inside the user's system—granting him full access. There was a patch available for the decompression flaw, but older, rich folks typically had no clue about security patches.

Is there such a thing? Is this description based on some real exploit?

This was published in December 2006.

Is it sensible to say "the operating system" was decompressing the image to render it?

Note this has nothing to do with security of PHP image uploading scripts. I'm asking about the decoding process of displaying a JPEG, not scripts taking input from remote users, nor files misnamed as .jpeg. The duplicate flagging I'm responding to looks poor even for a buzzword match; really nothing alike other than mentioning image files.

  • 31
    I can't find any evidence on Internet but I remember that I once received a JPG image which opened my CD tray (this was more than 12 years ago with Windows XP). Commented Aug 27, 2015 at 9:33
  • 30
    Malware in image files has been popular in fiction since the GDI+ exploit in 2004 was a real-world case. This example is quite plausible. Some are less so. Perhaps the worse was the case in Bones where someone etched a fractal image in a homicide victim's bone that took control of the protagonists' network when they uploaded photographs. That made my brain hurt.
    – Jon Hanna
    Commented Aug 27, 2015 at 11:41
  • 9
    This is not enough for a real answer, but a different image format, WMF, actually allowed you to run arbitrary code by design. It was designed for smart vector graphics in the 16-bit Windows days, and it was deemed a good tradeoff at the time. Fast forward to today, and the internet makes this a brutal security hole. There was also an exploit of TTF files (fonts). It's entirely possible that some parsers of JPG might have an exploitabel vulnerability in the same way.
    – Luaan
    Commented Aug 27, 2015 at 12:00
  • 25
    AFAIR that CD-tray opener wasn't a JPEG - it was VBS script, that IE executed despite jpeg file extension.
    – user158037
    Commented Aug 27, 2015 at 15:51
  • 5
    One of the exploits used on PS3 to play recorded PS2 games (not joking) was to open a specially crafted TIFF image on version 1.75 of the firmware. Also, there's the StageFright vulnerability on Android, which doesn't even require opening the message! So, yes, totally possible. Commented Aug 28, 2015 at 10:25

5 Answers 5


Is there such a thing?

Absolutely. Feeding malicious input to a parser is one of the most common ways of creating an exploit (and, for a JPEG, "decompression" is "parsing").

Is this description based on some real exploit?

It might be based on the Microsoft Windows GDI+ buffer overflow vulnerability:

There is a buffer overflow vulnerability in the way the JPEG parsing component of GDI+ (Gdiplus.dll) handles malformed JPEG images. By introducing a specially crafted JPEG file to the vulnerable component, a remote attacker could trigger a buffer overflow condition.


A remote, unauthenticated attacker could potentially execute arbitrary code on a vulnerable system by introducing a specially crafted JPEG file. This malicious JPEG image may be introduced to the system via a malicious web page, HTML email, or an email attachment.


This was published in December 2006.

The GDI+ JPEG parsing vulnerability was published in September 2004.

Is it sensible to say "the operating system" was decompressing the image to render it?

Sure; in this case, it was a system library that required an OS vendor patch to correct it. Often such libraries are used by multiple software packages, making them part of the operating system rather than application-specific.

In actuality, "the email application invoked a system library to parse a JPEG," but "the operating system" is close enough for a novel.

  • 24
    If I remember correctly, some of the initial "jail-breaking" methods for Sony's Playstation Portable (PSP) used a "specially crafted" image file that broke the PSP's decoder and allowed code embedded in the JPG to execute.
    – TripeHound
    Commented Aug 27, 2015 at 12:28
  • 1
    "attacker could potentially execute arbitrary code" is that boilerplate for any buffer overflow bug? Elevating privileges from the user-mode thread would be another problem.
    – JDługosz
    Commented Aug 27, 2015 at 16:25
  • 12
    @JDługosz, yes, that's a standardized description. Most CVEs and descriptions of security holes use a set of standard phrases like "[local|remote] attacker could potentially execute [arbitrary] [commands|code] [with [user|elevated] privileges]". The re-use of succinct keywords and phrases ("boilerplate") allows defenders to quickly assess risk - for example, the [local|remote] keyword is important in assessing risk. The phrasing used in the GDI+ announcement tells me the code runs with the privileges of the user opening the JPEG - in 2004-2006 Windows, often an Administrator!
    – gowenfawr
    Commented Aug 27, 2015 at 16:48
  • 1
    @TripeHound yep, rainbow colors, ghost in the shell cover picture and tiff format to use chickHEN. I still have those somewhere around here. Edit: yep, chickHEN but not tiff :/
    – ave
    Commented Aug 29, 2015 at 13:18
  • 1
    @MaxNanasy Yeah - but that's always the case; sometimes it's a bug in the code, sometimes it's a bug in the OS, sometimes it's a bug in the design. And as many examples have shown, a lot of the parsers do in fact have these bugs - buffer overflow leading to code execution being the one most often seen, I think. It's one of the reasons MS pushed .NET - as long as you stay safely in the managed environment, you've just eliminated one huge avenue of vulnerabilities. Of course, many parsers will use unsafe code for performance reasons, so it's not as good as it could be, but it still helps.
    – Luaan
    Commented Aug 31, 2015 at 8:15

Agreeing with others to say yes this is totally possible, but also to add an interesting anecdote:

Joshua Drake (@jduck), discovered a bug based on a very similar concept (images being interpreted by the OS) which ended up being named "Stagefright", and affected a ridiculous number of Android devices.

He also discovered a similar image based bug in libpng that would cause certain devices to crash. He tweeted an example of the exploit basically saying "Hey, check out this cool malicious PNG I made, it'll probably crash your device", without realising that twitter had added automatic rendering of inline images. Needless to say a lot of his followers started having their machines crash the instant the browser tried to load the image thumbnail in their feed.

  • 8
    Actually, the media framework is called "Stagefright", but the name is already catchy enough to name it "Stagefright bug". /offtopic
    – Lekensteyn
    Commented Aug 27, 2015 at 19:02

Unrealistic? There was recent critical bug in font definition parsing: https://technet.microsoft.com/en-us/library/security/ms15-078.aspx and libjpeg changenotes are full of security advisories. Parsing files[1] is hard: overflows, underflows, out of bounds access. Recently there were many fuzzing tools developed for semi-automatic detection of input that can cause crash.

[1] or network packets, XML or even SQL queries.

  • 1
    Yes... sooo hard with unmanaged code -.- If one would just code in managed code, buffer over/underflows would reduce to below 1% of their current impact on security...
    – Falco
    Commented Aug 28, 2015 at 11:35
  • 2
    If C compiler writers were interested in promoting robustness, C could outperform Java for many tasks where the semantics are "Given valid input, produce correct output; given invalid input, produce loosely-constrained output". Unfortunately, compiler writers seem to have no interest in that, and prefer to optimize out logic which would prevent security-critical forms of UB if it doesn't prevent what would otherwise be non-security-critical forms of UB from occurring in those same situations.
    – supercat
    Commented Aug 28, 2015 at 21:45
  • 1
    @Falco: Managed code isn't free; on the other hand, since hyper-modern C is eliminating many of the performance advantages C used to have in cases where programmers didn't care about precise behavior in cases of things like overflow, the only way I can see C remaining competitive is to officially catalog behaviors that weren't guaranteed by the Standard but were widely implemented, and allow programmers to specify them.
    – supercat
    Commented Aug 28, 2015 at 21:50
  • 5
    @Falco Unfortunately, managed runtimes also have their share of buffer overflows. The people who wrote Java did a horrible job of using defensive programming to guard the runtime's weak spots. In fact, I just ran into one in the latest Java (and reported it to Oracle, who confirmed it). It all boils down to an ill-advised pursuit of premature optimization. I wonder if we suddenly have a breakthrough and can build 20 GHz chips, will programmers finally embrace bounds checks and such. Or are they too fn stubborn. Commented Aug 29, 2015 at 10:41
  • 5
    @AleksandrDubinsky I wouldn't hold my breath - we've had a few increases in the order of magnitude of processing speeds, and so many still cling to avoiding bounds checking. The reasons they had so far will still be the same if CPUs get 1000x faster. There is hope, though - for example, Microsoft Research had been working on a full blown managed OS from the ground up - it wasn't designed for performance but rather safety and security, but for a research project, it still performed well enough. And when the whole OS is managed, you avoid the cost of communicating between managed and unmanaged.
    – Luaan
    Commented Aug 31, 2015 at 8:20

As others have pointed out, such attacks usually exploit buffer overflows.

Regarding the nuts-and-bolts of how, it's called a stack-smashing attack. It involves corrupting the call stack, and overwriting an address to legitimate code to be executed with an address to attacker-supplied code, which gets executed instead.

You can find details at insecure.org/stf/smashstack.html.


Yes this is possible:

A new variant of the nefarious Zeus banking trojan – dubbed ZeusVM – is concealed in JPG image files, according to the collaborative findings of Jerome Segura, senior security researcher with Malwarebytes, and French security researcher Xylitol.

The act is known as steganography – concealing messages or images in other messages or images.

In the case of ZeusVM, the malware's code is hidden in unassuming JPG images, a Monday blog post by Segura revealed. These photos serve as misdirection for ZeusVM to retrieve its configuration file.

“The JPG contains the malware configuration file, which is essentially a list of scripts and financial institutions - but doesn't need to be opened by the victim themselves,” Segura told SCMagazine.com in a Tuesday email correspondence. “In fact, the JPG itself has very little visibility to the user and is largely a cloaking technique to ensure it is undetected from a security software standpoint.”


  • 16
    While the technique is possible against a buggy JPEG decoder, this doesn't appear to be an example of such. This is simply encoding a configuration file in a JPEG to hide updates to an existing infection. OP appears to be asking about JPEG images as a vector for transmitting new infections. Commented Aug 26, 2015 at 19:20
  • 1
    I think this example is even more interesting than a simple infected image with which a user is likely needing to interact with it. This example rather shows a sofisticated malicious method that does not attract the attention of the user and may lead to man-in-the-browser attacks
    – user45139
    Commented Aug 26, 2015 at 19:37
  • 9
    The point of an infected image exploiting a JPEG decompressor is that there is no interaction required. If you have a buggy JPEG implementation, as in the GDI+ example provided by @gowenfawr, you can be compromised by simply viewing a webpage or email. Such images can be served by an advertising script on even trustworthy sites. That is far more interesting and worrisome than JPEG being used as an innocuous-seeming communication mechanism for a preexisting infection. Commented Aug 26, 2015 at 20:14
  • 6
    @TheJulyPlot I think you are misunderstanding how it works. In this example the Zeus Trojan uses a jpg to hide how it downloads its config file. A computer already infected with the trojan will download the image and extract the data. The image contains only the (hidden) config file, not the trojan, and has no mechanism for infecting systems on its own. You cannot be infected by simply downloading the image in a browser.
    – Robert
    Commented Aug 27, 2015 at 20:45
  • 2
    I'm not sure "sophisticated" really describes something like this. JPEG decoders generally just run to an EOF byte (if present) making this as easy as concatenating any other file to the end of the image file. cat img.jpg evil.zip > evil.jpg is all that's necessary.
    – alanaktion
    Commented Aug 28, 2015 at 17:18

You must log in to answer this question.

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