INFORMATION ABOUT MKFIFO

Make FIFOs (named pipes)
Creates the fifos requested, in the order specified, using mode 0666 modified by the current 

Syntax
       mkfifo [-m mode] fifo_name ...

Options
  -m      Set the file permission bits of newly-created
          directories to mode. The mode is specified as in chmod.

          In symbolic mode strings, the `+' and `-' operators
          are interpreted relative to an assumed initial mode of `a=rw'

mkfifo requires write permission in the parent directory.
mkfifo exits 0 if successful, and >0 if an error occurred.

A "FIFO" is a special file type that permits independent processes to communicate. One process opens the FIFO file for writing, and another for reading, after which data can flow as with the usual anonymous pipe in shells or elsewhere.

Attack Category	Path spoofing or confusion problem
Vulnerability Category	Indeterminate File/Path TOCTOU - Time of Check, Time of Use
Software Context	File Creation File I/O
Location	sys/stat.h
Description	mkfifo makes a FIFO special file with name pathname. mode specifies the FIFO's permissions. It is modified by the process's umask in the usual way: the permissions of the created file are (mode & ~umask). A FIFO special file is similar to a pipe, except that it is created in a different way. Instead of being an anonymous communications channel, a FIFO special file is entered into the file system by calling mkfifo. Once you have created a FIFO special file in this way, any process can open it for reading or writing, in the same way as an ordinary file. However, it has to be open at both ends simultaneously before you can proceed to do any input or output operations on it. Opening a FIFO for reading normally blocks the file until some other process opens the same FIFO for writing, and vice versa. See fifo(4) for non-blocking handling of FIFO special files. mkfifo() is vulnerable to classic TOCTOU attacks. A call to mkfifo() should be flagged if the first argument (the file name) is used previously in a check.
APIs Function Name Comments mkfifo use
Method of Attack	The key issue with respect to TOCTOU vulnerabilities is that programs make assumptions about atomicity of actions. It is assumed that checking the state or identity of a targeted resource followed by an action on that resource is all one action. In reality, there is a period of time between the check and the use that allows either an attacker to intentionally or another interleaved process or thread to unintentionally change the state of the targeted resource and yield unexpected and undesired results. The mknod() call is a use-category call, which when preceded by a check-category call can be indicative of a TOCTOU vulnerability. A TOCTOU attack in regards to mkfifo() can occur, for example, when a. A check for the existence of a filename (check call) occurs b. mkfifo() is executed Between a and b, an attacker could, for example, create a hard link to the pathname, resulting ultimately in a "different" pipe being created than what was expected.
Exception Criteria
Solutions Solution Applicability Solution Description Solution Efficacy Generally applicable to all mkfifo() calls. Utilize a file descriptor version of check and use functions, if possible. Effective. Generally applicable to all mkfifo() calls. The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check. Does not resolve the underlying vulnerability but limits the false sense of security given by the check. Generally applicable to all mkfifo() calls. Limit the interleaving of operations on files from multiple processes. Does not eliminate the underlying vulnerability but can help make it more difficult to exploit. Generally applicable to all mkfifo() calls. Limit the spread of time (cycles) between the check and use of a resource. Does not eliminate the underlying vulnerability but can help make it more difficult to exploit. Generally applicable to all mkfifo() calls. Recheck the resource after the use call to verify that the action was taken appropriately. Effective in some cases.
Signature Details	int mkfifo(const char *pathname, mode_t mode);
Examples of Incorrect Code /* Check added */ #include "sys/types.h" #include "sys/stat.h" int status; int check_status; struct stat statbuf; ... check_status=stat("/home/cnd/mod_done", &statbuf); ... status = mkfifo("/home/cnd/mod_done", S_IWUSR | S_IRUSR | S_IRGRP | S_IROTH);
Examples of Corrected Code /* No check needed */ #include "sys/types.h" #include "sys/stat.h" int status; ... status = mkfifo("/home/cnd/mod_done", S_IWUSR | S_IRUSR | S_IRGRP | S_IROTH);
Source References	Viega, John & McGraw, Gary. Building Secure Software: How to Avoid Security Problems the Right Way. Boston, MA: Addison-Wesley Professional, 2001, ISBN: 020172152X, pp 222 UNIX man page for mkfifo() The IEEE and The Open Group. The Open Group Base Specifications Issue 6; IEEE Std 1003.1, 2004 Edition (2004).
Recommended Resource
Discriminant Set Operating System UNIX Languages C C++