On a POSIX system, is there a possibility for a file which is non-executable and read-only (aka with a mode 444) to run malicious code on a machine?

If so, can you explain how it would do so?

  • Please elaborate on the platform. I'm assuming it's a POSIX platform given that you specified 444, but please be explicit.
    – iAdjunct
    Commented Dec 30, 2015 at 1:22
  • For discussion purposes, let's just say x86_64, and specifically an Apple OSX machine. Does that platform change the answer?
    – Idr
    Commented Dec 30, 2015 at 1:23
  • 1
    Yes, because it's a POSIX-based system (UNIX and Linux are both POSIX-based systems). The methods by which something is "executable" is different on POSIX-based systems vs. Windoze systems.
    – iAdjunct
    Commented Dec 30, 2015 at 1:26
  • 2
    Related thread: How can normal files hide a virus?. It is the Windows counter-part if this question, but some answers are OS independent. Of interest is also How can a font be used for privilege escalation? since fonts are typically read-only files (the only difference is that on Unix system such attack would have to target an X Server vulnerability, which usually runs as root too and suffered from similar vulnerabilities). Commented Dec 30, 2015 at 10:46
  • 1
    Yes, on any operating system. All you need is a severe-enough bug in whatever program reads the file in order to have the possibility of malicious code execution. Such vulnerabilities are uncommon, though certainly not unheard of.
    – aroth
    Commented Dec 31, 2015 at 0:34

5 Answers 5


Yes, something just has to execute it. The X flag hints to the shell that it can be directly executed, but that doesn't stop other programs from executing it if they know how.

For example, if you have a file a.sh which is not executable to the shell, you can execute it by calling bash a.sh (which tells bash explicitly to execute it). If you have a non-executable file a.py, you can execute it by calling python a.py. I'd imagine there's also a way to tell the OS to execute a binary ELF file, but I don't know the command off hand.

There are also a whole class of things which don't require you to do anything in particular to make it execute malicious code. PDFs and Adobe Flash files in particular have had some well-known holes which allowed the simple act of reading a file to execute malicious code. There are also some files which, in specific places, and be auto-executed (especially on Windows). Also, if the file is compressed, it may contain a buffer-overflow virus for the decompressor. The file also may be even more malicious, taking advantage of a yet-unknown bug in the file system or something else really low-level.

Bottom line: the only way to guarantee something won't infect your computer is to never do anything with anything.

  • 12
    It's getting quite a contrived example - yes, you're understanding is largely correct - but how can you be sure that no other program will look and try to interpret it? People some time ago thought it was impossible catching a "virus" by just downloading an email and not opening it. Now this is what IS is about. What if your OS looks at a read-only image, trying to show a thumbnail, and triggers a buffer overflow in the process? What if you try to drop the file to the trashcan, but accidently drop it on a program that misinterprets it? What if a fellow human trusts it for some reason?
    – chexum
    Commented Dec 30, 2015 at 1:51
  • 5
    Not so contrived @chexum - en.wikipedia.org/wiki/Stagefright_(bug) is an example Commented Dec 30, 2015 at 2:49
  • 2
    @NeilSmithline - I was only criticising the notion of "but it will require some other process to execute the file", pointing out that it would not be unexpected for a data file to wreak havoc. The key thing is, a data (not executable) file would not be a reason to worry, if nothing is trying to parse it. But similarly, an executable file should not cause problems either. The problem is that we cannot foresee how a file, or any of its properties (name, extension, size) is used, interpreted, or parsed by the environment in an unexpected way.
    – chexum
    Commented Dec 30, 2015 at 13:22
  • 2
    You can run an ELF by passing it to ld.so (if I remember correctly)
    – wb9688
    Commented Dec 30, 2015 at 18:55
  • 3
    @ldr : Strictly, no. If any process interprets its contents, it can produce malicious results. Virus scanners have been subverted when scanning files. Web browsers and other file downloading software have been subverted by receiving a malformed bitstream claiming to be a file download. Webservers have been subverted by asking them to retrieve malicious uploads. No specific executable receives these files as an argument to execute and yet the hazard exists. Do you actually know all the processes that will or may touch a file when you download it? Commented Dec 30, 2015 at 22:42

Let's say you have the file myscript containing the following:

  echo "Hello, World!"

If you make this file executable and run it with ./myscript, then the kernel will see that the first two bytes are #!, which means it's a script-file. The kernel will then use the rest of the line as the interpreter, and pass the file as its first argument. So, it runs:

     /bin/bash myscript

and bash reads the file and executes the commands it contains. another way of executing a file without execute bit set is:

   #. myscript

a dot followed by a space and then the name of file.

Thus, for bash (or whatever interpreter your script requires) to "execute" the script, it only needs to be able to read the file.

So, for scripts, the execute bit just makes it a bit more convenient to execute it. As long as bash is executable, you can always run bash with the script file as argument

  • I learnt a new thing today. . file executes a file without the x bit set. Thanks.
    – Floris
    Commented Dec 30, 2015 at 22:48
  • yes , it sounds interesting , :) welcome
    – Ijaz Ahmad
    Commented Dec 30, 2015 at 22:56
  • 1
    It's worth noting that . is another way of calling source.
    – cubuspl42
    Commented Dec 31, 2015 at 9:50
  • 1
    Note that .|source executes the named file in the current shell environment, rather than invoking another shell as a child process. Commented Dec 31, 2015 at 10:13

This can be true not only with scripts like the other examples shown on all answers. Basically, if the software that reads a file have a bug, every file is an vector for malicious code execution, using a pretty vast range of techniques(overflow, mem corruption, arbitraty software execution...). Examples:

  • Exploit.Win32.AdobeReader.K - This malicious PDF file takes advantage of a vulnerability (CVE-2007-5020)on the URI handling of PDF files. This vulnerability affects IE7, Adobe Acrobat, and Adobe Reader on some platforms.
  • Zero Day QuickTime mvhd - The specific flaw exists within the 'mvhd' atom. By providing a malformed version and flags, an attacker is able to create controllable memory corruption, and trigger an arbitrary write operation. By exploiting this, an attacker could execute code in the context of the current user. CVE-2014-4979

A file itself may not be dangerous just sitting there. But depending on the program the will try to read it, it could cause problems. As well if the file can be read it can be copied. So it could be copied and renamed into a executable file.

So say you are using DOS/Windows and you have a file something.txt and you copy it to a file called something.bat you can now execute it.

If you have say an HTML file (or html content) you can load it in your browser and if your browser has a vulnerability in Javascript that program can cause harm.

In theory if the file is just sitting there it could be still dangerous, if by somehow the file allocation table (FAT) for the file system has some issues, and is executing a program then due to improper fragmentation it could jump to where your malicious file is and run such code. This type of actions on some Operating Systems can be done via a buffer overflow.


Yes you can. The classic example for binaries is to use the ELF-interpreter as in the example below.

$ cp /bin/ls /tmp/ls
$ chmod a-x /tmp/ls
$ /lib/ld-linux.so.2 /tmp/ls

Or for x86-64 systems:

$ /lib64/ld-linux-x86-64.so.2 /tmp/ls

The same goes for shell scripts.

$ echo "#!/bin/bash" > /tmp/hello
$ echo "echo 'hello world" >> /tmp/hello
$ bash /tmp/hello

These are basic example when we have a new auditor or risk manager or security officer who thinks we need to tidy up things. The resolve this is to go the path of SELinux on Linux systems as it also restricts other escalation paths as others also mentioned.

You must log in to answer this question.

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