S 4.23 Secure invocation of executable files

Initiation responsibility: IT Security Officer, Administrator

Implementation responsibility: User, Administrator

Executable files can be started directly. Application data such as text files, on the other hand, can only be opened by using a corresponding program. In Windows, executable files can be recognised by their file extensions (for example .exe, .com, .vbs, .bat, .cmd), and in Unix by file rights (x flag).

It must be ensured that only approved versions of executable files and no implanted modified versions (particularly Trojan horses) are retrieved (see S 2.9 Ban on using non-approved hardware and software).

An attacker may change an executable file to the extent that he/she is granted the privileges of the user executing the file. In order to prevent this, executable files must be read-only. Write access must only be granted to administrators.

Executable files which write rights are required for, e.g. because they are under development, must only be used in separate areas. The same holds true for new software that is to be tested for later use on a production system. For this, separate test systems or specific user accounts without any other privileges may be used, for example. This is the only way to prevent these applications from doing harm.

Even software which has already been tested may have adverse effects on security. This especially applies to very complex applications such as web servers. When applications are started, it must already be ensured that each process is only granted the number of rights absolutely necessary. This way, the damage occurring as a consequence of a successful attack may be limited. These services must not be started with administrator rights, if possible. User accounts with limited privileges are also suitable for this. Strict separations of rights, for example with the help of chroot environments in Unix or Linux, with the power of limiting the occurring damage must be taken into consideration.

Furthermore, it must be ensured that the desired, approved version can be executed. Otherwise, an attacker could copy a modified file with the same name into a directory he/she has write access for. If the file is searched for in the directories during retrieval, the modified file could be executed instead of the desired file.

For many operating systems, the directories that are to be searched for the executable files are entered in the corresponding sequence in the PATH variable. The number of specified directories should be kept low and manageable. Relative directory information including the respective current working directory must not be contained as information in the PATH variable. Executable files should be stored in dedicated directories. Only the respective owner may be granted write rights in the directories contained in a PATH variable. This must be checked regularly.

Review questions:

© Federal Office for Information Security. All rights reserved.