File names on many operating systems, including Windows and UNIX, may be used to access special files, which are actually devices. Reserved MS-DOS device names include AUX
, CON
, PRN
, COM1
, and LPT1
. Device files on UNIX systems are used to apply access rights and to direct operations on the files to the appropriate device drivers.
Performing operations on device files that are intended for ordinary character or binary files can result in crashes and denial-of-service attacks. For example, when Windows attempts to interpret the device name as a file resource, it performs an invalid resource access that usually results in a crash [Howard 2002].
Device files in UNIX can be a security risk when an attacker can access them in an unauthorized way. For instance, if attackers can read or write to the /dev/kmem
device, they may be able to alter their priority, UID, or other attributes of their process or simply crash the system. Similarly, access to disk devices, tape devices, network devices, and terminals being used by other processes can lead to problems [Garfinkel 1996].
On Linux, it is possible to lock certain applications by attempting to open devices rather than files. Consider the following example:
/dev/mouse /dev/console /dev/tty0 /dev/zero
A Web browser that failed to check for these devices would allow an attacker to create a website with image tags such as <IMG src="file:///dev/mouse">
that would lock the user's mouse.
Noncompliant Code Example
In this noncompliant code example, the user can specify a locked device or a FIFO (first-in, first-out) file name, causing the program to hang on the call to fopen()
:
#include <stdio.h> void func(const char *file_name) { FILE *file; if ((file = fopen(file_name, "wb")) == NULL) { /* Handle error */ } /* Operate on the file. */ fclose(file); }
Compliant Solution (POSIX)
POSIX defines the O_NONBLOCK
flag to open()
, which ensures that delayed operations on a file do not hang the program [Open Group 2004].
When opening a FIFO with
O_RDONLY
orO_WRONLY
set:
- If
O_NONBLOCK
is set, anopen()
for reading-only shall return without delay. Anopen()
for writing-only shall return an error if no process currently has the file open for reading.- If
O_NONBLOCK
is clear, anopen()
for reading-only shall block the calling thread until a thread opens the file for writing. Anopen()
for writing-only shall block the calling thread until a thread opens the file for reading.When opening a block special or character special file that supports non-blocking opens:
- If
O_NONBLOCK
is set, theopen()
function shall return without blocking for the device to be ready or available. Subsequent behavior of the device is device-specific.- If
O_NONBLOCK
is clear, theopen()
function shall block the calling thread until the device is ready or available before returning.Otherwise, the behavior of
O_NONBLOCK
is unspecified.
Once the file is open, programmers can use the POSIX lstat()
and fstat()
functions to obtain information about a named file and the S_ISREG()
macro to determine if the file is a regular file. (See FIO05-C. Identify files using multiple file attributes.)
Because the behavior of O_NONBLOCK
on subsequent calls to read()
or write()
is unspecified, it is advisable to disable the flag after it has been determined that the file in question is not a special device.
When available (Linux 2.1.126+, FreeBSD, Solaris 10, POSIX.1-2008), the O_NOFOLLOW
should also be used. (See POS01-C. Check for the existence of links when dealing with files.) When O_NOFOLLOW
is not available, symbolic link checks should use the method from POS35-C. Avoid race conditions while checking for the existence of a symbolic link.
#include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #ifdef O_NOFOLLOW #define OPEN_FLAGS O_NOFOLLOW | O_NONBLOCK #else #define OPEN_FLAGS O_NONBLOCK #endif void func(const char *file_name) { struct stat orig_st; struct stat open_st; int fd; int flags; if ((lstat(file_name, &orig_st) != 0) || (!S_ISREG(orig_st.st_mode))) { /* Handle error */ } /* A TOCTOU race condition exists here, see below. */ fd = open(file_name, OPEN_FLAGS | O_WRONLY); if (fd == -1) { /* Handle error */ } if (fstat(fd, &open_st) != 0) { /* Handle error */ } if ((orig_st.st_mode != open_st.st_mode) || (orig_st.st_ino != open_st.st_ino) || (orig_st.st_dev != open_st.st_dev)) { /* The file was tampered with. */ } /* Optional: drop the O_NONBLOCK now that we are sure this is a good file. */ if ((flags = fcntl(fd, F_GETFL)) == -1) { /* Handle error */ } if (fcntl(fd, F_SETFL, flags & ~O_NONBLOCK) != 0) { /* Handle error */ } /* Operate on the file. */ close(fd); }
This code contains an intractable TOCTOU (time-of-check, time-of-use) race condition under which an attacker can alter the file referenced by file_name
following the call to lstat()
but before the call to open()
. The switch will be discovered after the file is opened, but opening the file cannot be prevented in the case where this action itself causes undesired behavior.
Essentially, an attacker can switch out a file for one of the file types shown in the following table with the specified effect.
File Types and Effects
Type | Note on effect |
---|---|
Another regular file | The |
FIFO | Either |
Symbolic link |
|
Special device | Usually the |
This TOCTOU race condition can be prevented if the effected files are maintained in a secure directory. (See FIO15-C. Ensure that file operations are performed in a secure directory.)
Compliant Solution (Windows)
Microsoft documents a list of reserved identifiers that represent devices, as well as have a device namespace to be used specifically by devices [MSDN]. This compliant solution tests the given file name against these constructs:
#include <ctype.h> #include <stdbool.h> #include <stdlib.h> #include <string.h> #include <stdio.h> static bool isReservedName(const char *path) { /* This list of reserved names comes from MSDN. */ static const char *reserved[] = { "nul", "con", "prn", "aux", "com1", "com2", "com3", "com4", "com5", "com6", "com7", "com8", "com9", "lpt1", "lpt2", "lpt3", "lpt4", "lpt5", "lpt6", "lpt7", "lpt8", "lpt9" }; char *lower; char *temp; bool ret = false; /* First, check to see if this is a device namespace, which always starts with \\.\, since device namespaces are not legal file paths. */ temp = strstr(path, "\\\\.\\"); if (temp == path) { return true; } /* Since Windows uses a case insensitive file system, operate on a lowercase version of the given filename. Note: this ignores globalization issues and assumes ASCII characters. */ lower = (char *)malloc(strlen(path) + 1); if (!lower) { return false; } temp = lower; while (*path) { *lower++ = tolower(*path++); } lower = temp; /* Compare against the list of ancient reserved names. */ for (size_t i = 0; !ret && i < sizeof(reserved) / sizeof(*reserved); ++i) { if (0 == strcmp(lower, reserved[i])) { ret = true; } } free(lower); return ret; }
While it may be tempting to use the Win32 GetFileType() function, it is a dangerous API to use in this case. If the file name given identifies a named pipe, and that pipe is currently blocking on a read request, the call to GetFileType()
will block until the read request completes. That allows an attacker to effectively launch a denial-of-service attack on your application. Furthermore, the act of opening a file handle may cause further action to be taken, such as line states being set to their default voltage when opening a serial device.
Risk Assessment
Allowing operations that are appropriate only for files to be performed on devices can result in denial-of-service attacks or more serious exploits depending on the platform.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
FIO32-C | medium | unlikely | medium | P4 | L3 |
Automated Detection
Tool | Version | Checker | Description |
---|---|---|---|
Compass/ROSE |
|
| Could detect some violations of this rule. This rule applies only to untrusted file name strings, and ROSE cannot tell which strings are trusted and which are not. The best heuristic is to note if there is any verification of the file name before or after the |
Fortify SCA | 5.0 |
|
|
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
Bibliography
[Garfinkel 1996] | Section 5.6, "Device Files" |
[Howard 2002] | Chapter 11, "Canonical Representation Issues" |
[Open Group 2004] | open() |