108

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.

David Mulder
  • 1,349
  • 1
  • 8
  • 16
JDługosz
  • 1,138
  • 2
  • 7
  • 12
  • 1
    Unfortunately, almost any format can be poisoned. Even some damaged files can crash the built-in decompression and/or decoding routines. – cybernard Aug 27 '15 at 03:34
  • 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). – A.L Aug 27 '15 at 09: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 Aug 27 '15 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 Aug 27 '15 at 12:00
  • If jpeg doesn't allow arbitrarily code by design, how can it have the same kind of vulnerability? – JDługosz Aug 27 '15 at 15:39
  • 25
    AFAIR that CD-tray opener wasn't a JPEG - it was VBS script, that IE executed despite jpeg file extension. – user158037 Aug 27 '15 at 15:51
  • It was a common method to root the first version of the iPhone. – arivero Aug 27 '15 at 16:44
  • @arivero "it" refers to ...? (A decoding exploit or something in a previous comment) – JDługosz Aug 27 '15 at 16:55
  • @user158037 thanks, I didn't remember if it was the image viewer or IE which had this flaw. – A.L Aug 27 '15 at 17:03
  • @JDługosz er... "it" refers to your original question, "decompressing a JPEG image". – arivero Aug 27 '15 at 17:06
  • Just viewing a page with a jpeg file would "root" the phone? How handy. Got a link reference for that? – JDługosz Aug 27 '15 at 22:03
  • I'm pleasantly surprised to see Daemon here. I read it a few years back, and it's amazing how closely he stuck to realistic, pre-existing technology. In fact, just this past week, I bumped into a hypersonic sound system (the type of sound system that was in Sobol's house) in a Best Buy, and it was quite interesting to experience. – Brandon Anzaldi Aug 27 '15 at 23:04
  • possible duplicate of [Can malware be attached to an image?](http://security.stackexchange.com/questions/55061/can-malware-be-attached-to-an-image/) – jamesdlin Aug 27 '15 at 23:08
  • 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](http://security.stackexchange.com/questions/95165/how-exactly-does-the-stagefright-vulnerability-work-on-android) on Android, which doesn't even require opening the message! So, yes, totally possible. – Ismael Miguel Aug 28 '15 at 10:25
  • Reportedly, a new one is going on atm. [Source](http://steamcommunity.com/groups/reddit#announcements/detail/145594019967735932) – ave Sep 03 '15 at 20:42
  • As a bonus, JPEG+ZIP is a steganography technique as well - one ignores extra content at the end of the file, the other at the start of a file. [Example.](https://github.com/MiroslavVitkov/scripts/tree/master/crypto) – Vorac Jul 06 '20 at 07:05

5 Answers5

184

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.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 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 Aug 27 '15 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 Aug 27 '15 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 Aug 27 '15 at 16:48
  • This exploit would only be possible if the decompression algorithm in question had a bug in it that allowed arbitrary code execution, correct? – Max Nanasy Aug 29 '15 at 03:19
  • 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 Aug 29 '15 at 13:18
  • @JDługosz They use the term "attacker could potentially execute arbitrary code" rather than "buffer overflow" because the effect is more important for decision making purposes than the actual method use to do it. For example, I don't care if you buffer overflow to inject code, or if you jailbreak by opening up a new process that receives and issues your command. The important effect is that the attacker can now issue bytecodes on my machine. – Cort Ammon Aug 30 '15 at 20:25
  • 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 Aug 31 '15 at 08:15
53

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.

Nic Barker
  • 1,170
  • 7
  • 11
  • 8
    Actually, the media framework is called "Stagefright", but the name is already catchy enough to name it "Stagefright bug". /offtopic – Lekensteyn Aug 27 '15 at 19:02
13

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.

user158037
  • 271
  • 1
  • 6
  • 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 Aug 28 '15 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 Aug 28 '15 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 Aug 28 '15 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. – Aleksandr Dubinsky Aug 29 '15 at 10:41
  • MS15-078 is even more alarming because the Adobe font driver thing *runs in kernel mode*. – Matt Nordhoff Aug 31 '15 at 02:33
  • 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 Aug 31 '15 at 08:20
2

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.

Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
Emilio M Bumachar
  • 507
  • 2
  • 9
1

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.”

Source.

Community
  • 1
TheJulyPlot
  • 7,669
  • 6
  • 30
  • 44
  • 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. – Stephen Touset Aug 26 '15 at 19:20
  • Well if you want to be a pedant about it, parsing and decompression are two separate things even in jpegs and wider computer science. One describes data *in a manner of speaking* the other one, well it decompresses something. Either way, the point being malware can be delivered via jpegs using a number of discreet methods. – TheJulyPlot Aug 26 '15 at 19:33
  • 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 –  Aug 26 '15 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. – Stephen Touset Aug 26 '15 at 20:14
  • 1
    I get your point, but not the relevance to my comment. You can be infected by simply downloading the image in a browser by this as well. gowenfawrs example was a good example yes, I agree. Closer to the theoretical example in the original question. Anyway as I said, there are many different methods of delivering malware via a jpeg, including this one which I posed merely as an example of jpegs being malicious. https://blog.malwarebytes.org/security-threat/2014/02/hiding-in-plain-sight-a-story-about-a-sneaky-banking-trojan/ – TheJulyPlot Aug 27 '15 at 09:41
  • 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 Aug 27 '15 at 20:45
  • I'm not misunderstanding at all..in fact that was described in the link I posted. – TheJulyPlot Aug 27 '15 at 20:48
  • 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 Aug 28 '15 at 17:18