Can I send instructions embedded in an image to a target, if I know his CPU architecture?
If I know the CPU architecture of a target, can I send instructions embedded in an image?
19Possible duplicate of Can malware be attached to an image?– AndersOct 29, 2018 at 8:40
46Sure you can. But it's not going to execute them. Actually most bytes are valid CPU instructions.– user253751Oct 29, 2018 at 23:36
21sure, just write then on a piece of paper and take a photo... :)– JasenOct 30, 2018 at 11:19
Note that there are image formats that explicitly rely on "arbitrary code execution" (mostly from the old era when compatibility and saving memory and CPU was more important than securing images). The most notable is probably WMF, where the feature was very reasonable and safe in the original implementation, but the safety was lost when porting the code from Windows 3.0 (16-bit) to Windows NT (32-bit, and only on x86). So this was one of the rare cases where e.g. Windows 98 (desktop) was safer than Windows NT (server/professional) :)– LuaanOct 31, 2018 at 9:54
Did vulnerabilities lead to asking this question?– jpmc26Oct 31, 2018 at 22:55
CPU instructions are given in what are called opcodes, and you're right that those live in memory just like your image. They live in conceptually different "areas" of memory, though.
For instance, you could imagine an opcode "read" (0x01) that reads a byte of input from stdin and puts it somewhere, and another operand "add" (0x02) that adds two bytes. Some opcodes can take arguments, so we'll give our example opcodes some: the "read" opcode takes an operand for where to store the byte it reads, and the "add" one takes three operands: two for where to read its inputs, and one for where to write the result to.
0x01 a1 // read a byte to memory location 0xa1 0x01 a2 // read a byte to memory location 0xa2 0x02 a1 a2 a3 // read the bytes at locations 0xa1 and 0xa2, add them, // and write the result to location 0xa3
This is typical of how a lot of instructions work: most of them just operate on data that's in memory, and some of them put new data into memory from the outside world (from reading stdin, in this example, or from reading a file or network interface).
While it's true that the the instructions and the data they operate on are both in memory, the program will only run the instructions. It's the job of the CPU, the OS, and the program to all make sure that happens. When they fail, you can in fact load data into the execution space, and it's a serious security bug. Buffer overflows are probably the most famous example of such a bug. But other than those kinds of bugs, you can essentially think of the data space and the execution space as being separate chunks of CPU.
In a toy computer, using the example above, the memory might look something like:
(loc) | Initial | After op 1 | After op 2 | After op 3 | 0x00 | *01 a1 | 01 a1 | 01 a1 | 01 a1 | 0x02 | 01 a2 | *01 a2 | 01 a2 | 01 a2 | 0x04 | 02 a1 a2 a3 | 02 a1 a2 a3 | *02 a1 a2 a3 | 02 a1 a2 a3 | 0x08 | 99 | 99 | 99 | *99 | ... 0xa1 | 00 | 03 | 03 | 03 | 0xa2 | 00 | 00 | 04 | 04 | 0xa3 | 00 | 00 | 00 | 07 |
In that example, the asterisk (
*) points to the next opcode that will be executed. The leftmost column specifies the starting memory location for that line. So for instance, the second line shows us two bytes of memory (with values
a2) at locations 0x02 (explicitly in the left-hand column) and 0x03.
(Please understand that this is all a big simplification. For instance, in a real computer the memory can be interleaved -- you won't just have one chunk of instructions and one chunk of everything else. The above should be good enough for this answer, though. )
Note that as we run the program, the memory in areas 0xa1 - 0xa3 changes, but the memory in 0x00 - 0x08 does not. The data in 0x00 - 0x08 is our program's executable, while the memory in areas 0xa1 - 0xa3 is memory the program uses to do the number crunching.
So to get back to your example: the data in your jpeg will get loaded into the memory by opcodes, and will be manipulated by opcodes, but will not be loaded into their same area in memory. In the example above, the two values 0x03 and 0x04 were never in opcode area, which is what the CPU executes; they were only in the area that the opcodes read and write from. Unless you found a bug (like a buffer overflow) which let you write data into that opcode space, your instructions won't be executed; they'll just be the data that gets manipulated by the program's execution.
5Your answer is at best partially correct. Apart from the simplification that all data must reside on the "stack", it is a wrong assumption that manipulating data on the stack cannot be used for arbitrary code execution.– JimmyBOct 30, 2018 at 14:10
17@JimmyB He literally says it's a big simplification, and the question isn't talking about exploits, rather just inserting code into an image. The answer does a good job of explaining in simple terms why code inserted into an image won't just execute.– ClonkexOct 30, 2018 at 22:58
1@Blackhawk: Almost everything about the stack is wrong. It's sort of vaguely similar to how stack machine architectures operate, but most modern computers don't use a stack machine architecture, and even stack machines use the stack as a temporary holding ground for instruction inputs and outputs, not as where all data is kept. (The call stack used in modern computer architectures is a different thing, and that stack doesn't work like this answer describes either.) Oct 30, 2018 at 23:03
10While the "not unless you exploit a bug" part is correct, this answer goes into lots and lots of unnecessary and wrong detail that makes it seem more informative to an inexperienced reader, but actually makes the answer worse than the short but correct answers that didn't get accepted. Oct 30, 2018 at 23:06
3@yshavit I think you should remove the statement "While it's true that the the instructions and the data they operate on are both in memory, they're in different parts of memory." because it is at best misleading and at worst just plain wrong. Nov 1, 2018 at 20:48
Other answers give a good technical explanation but let me try with an analogy:
Please send your credit card number to email@example.com
Did you read it?
Did you do it?
It's more or less the same for your CPU. Reading something is not the same as executing it.
19It's not the best analogy though because as humans we can stop and decide if something is a good idea, but a computer cannot. The computer has to "decide" before starting. Oct 29, 2018 at 13:47
27+1 for trying to explain by analogy. Just because I read a set of instructions, doesn't mean I actually do them.– A COct 29, 2018 at 14:44
7@CaptainMan it is a very good analogy. It would not surprise me that much if after a number of years "firstname.lastname@example.org" does not receive credit card numbers b/c of this posting.– emoryOct 29, 2018 at 16:45
65What's the next step? It's been nearly 8 hours since I mailed and I still haven't heard back. Oct 29, 2018 at 17:20
5@emory Do you really think someone who can read english well enough to find this page and read that sentence will not understand the context that it's posted in, to the point where they mistake it as instructions that they must perform? Oct 29, 2018 at 17:28
Can you send them? Yes, of course. Just assemble them and stick them somewhere in the image file.
Will the target execute them? No, not unless you already have control over the target (and can thus put a program there to read and execute them), or you find some exploit in an image viewer and get the image to load in it.
36No, why would it? Oct 29, 2018 at 1:55
21Processing bytes of data is different than executing those bytes. One doesn't imply the other. Oct 29, 2018 at 2:25
17Yes, but some bytes get executed and some just get treated as data. Oct 29, 2018 at 2:38
69@Faminha102 If you were walking outside and stumble upon a piece of paper with some instructions on it, would you follow those instructions? Probably not. You might still read and understand those instructions, but you wouldn't act on them because you know that they aren't intended for you. A similar idea applies here.– tlng05Oct 29, 2018 at 5:32
12The misconception here may come from the observation that double-clicking an image displays ("starts") the image, just as double-clicking an executable starts the executable.– JimmyBOct 30, 2018 at 14:13
You could if your target used a version of Internet Explorer from before August 2005 to view a JPG. Or if they were going to open a PNG in Windows Media Player on Windows 98 with no security updates installed. And so on.
There was a lot of old software that used to have bugs where, if you made an image file in which the first part of the image file lied outrageously about the size and location of the pixel data in the file, the software could do something wrong and accidentally jump to code at the wrong address or write data from the file in a place where program code should be. I recall one of these hacks involved a file whose header claimed the image had negative size. You probably can't do this with more recent versions of Internet Explorer, or Edge, because everyone knows about the problem now and Microsoft did their best to fix it.
Today's operating systems have some protective measures in place to make it difficult (but not completely impossible) to achieve anything really bad if you find a new way to hack a program using a method like this. Areas of memory can be set so they cannot be executed. Programs have separate virtual address spaces so they can't accidentally access each other's memory. Some OS components are loaded at unpredictable memory locations so it's not simple for malicious code to find and use them.
1Further details: security.stackexchange.com/questions/97856/…– user3490Oct 29, 2018 at 15:30
6The eminent German blogger Felix von Leitner often emphasizes that, paradoxically, virus scanners expose huge attack surfaces because they must be able to open all file formats while running with maximum rights. So you don't even have to open the JPEG; it may be sufficient if your anti virus program attempts to scan it in the background. Oct 30, 2018 at 14:35
Exactly. JPEGs most certainly have infected computers. A Google search just now for jpeg malware returned this site explaining it. Oct 31, 2018 at 2:01
1Vulnerabilities in some software existed at least as recently as 2012: docs.microsoft.com/en-us/security-updates/…– jpmc26Oct 31, 2018 at 22:58
No. Image files such as JPEG files don't execute code, they are simply rendered and displayed.
If you want to hide some information in a file that's called Steganography, but that only hides information, it doesn't execute any instructions.
For a file to run code it has to be an executable, or be run by another program which reads the file, then executes the commands in the file.
In this case the rare instance when an image could result in executing code is if there were a bug in the software which rendered the image based off the file. This has happened in the past, but it's exceedingly rare. For all practical purposes an image can't run instructions.
This of course isn't the case for PDFs, Adobe Flash, etc.
1PDFs have more functionality, they can be interactive, load external resources, embed other files, etc. They aren't as dangerous as Word/Execl files though.– DaisetsuOct 29, 2018 at 2:10
1Could you elaborate more? Oct 29, 2018 at 2:19
9"Image files such as JPEG files don't execute code": I find this a bit inprecise. Even most executable files do not execute code, they are being executed.– phresnelOct 29, 2018 at 11:09
2@Captian Man, to have a file execute directly (without being invoked by another process which would interpret it's instructions) a program has to be a binary executable (ELF binary for Linux, PE for Windows). You can't simply take a binary, and create a valid JPEG file. The headers for a JPEG and PE/ELF don't align.– DaisetsuOct 29, 2018 at 18:51
You can, IF you also know what software stack will touch the image on the receiving side, AND IF there are unresolved security vulnerabilities in that software stack.
Simply putting the instructions in the JPEG file does nothing.
However, if there is a known way to make a certain exact JPEG reader implementation crash on a malformed JPEG file in a way that it will copy data from the image file where that data does not belong (like, on top of variables that contain program control flow information like function pointers or return addresses), and if OS or hardware level countermeasures (eg DEP) do not stop that from happening, there is a realistic chance. Such vulnerabilities have existed in (and do exist in legacy) real-world implementations.
The short version is no, because computers (SHOULD) know the difference between data and instructions. The worst you SHOULD be able to do with a JPEG is something like a zip-bomb or something that crashes some JPEG decompression routines. A program to load & display a JPEG will not be trying to RUN any of the data in the file, only read it and process it - and if it hits some unexpectedly not-jpeg data it will either stop or crash, or just show a really messed up picture.
HOWEVER, sometimes (I'm looking at you, Microsoft) people try and write helpful software that can be vulnerable by (for example) trying to automatically load & display e-mail attachments, create document formats that can contain scripts/macros, etc. and this is where a malicious file can cause damage.
The classic (and by now hopefully defunct/protected against) example is e-mail attachments called something like
.jpg.exe where the file is really an executable and Windows will treat it as such, but because Windows hides the extension (hiding the last .exe part) people see
file.jpg and click on it, causing the OS to run it.
It's the difference between reading a book and acting out the content of the book - if the book says "go and punch someone" you're not going to do it, because the words (data) in the book is not controlling your brain even though your brain is processing that data.