vfork function introduces many portability and security issues. There are many cases in which undefined and implementation-specific behavior can occur, leading to a denial-of-service vulnerability.
According to the
vfork man page,
vfork()function has the same effect as
fork(), except that the behavior is undefined if the process created by
vfork()either modifies any data other than a variable of type
pid_tused to store the return value from
vfork(), or returns from the function in which
vfork()was called, or calls any other function before successfully calling
_exit()or one of the
execfamily of functions.
Furthermore, older versions of Linux are vulnerable to a race condition, occurring when a privileged process calls vfork(), and then the child process lowers its privileges and calls execve(). The child process is executed with the unprivileged user's UID before it calls execve().
Because of the implementation of the
vfork() function, the parent process is suspended while the child process executes. If a user sends a signal to the child process, delaying its execution, the parent process (which is privileged) is also blocked. This means that an unprivileged process can cause a privileged process to halt, which is a privilege inversion resulting in a denial of service.
This code example shows how difficult it is to use
vfork() without triggering undefined behavior. The lowering of privileges in this case requires a call to
setuid(), the behavior of which is undefined because it occurs between the
vfork() and the
fork() instead of
vfork() in all circumstances.
Noncompliant Code Example
This noncompliant code example calls
vfork() and then
execve(). As previously discussed, a
execve() pair contains an inherent race window on some implementations.
This compliant solution replaces the call to
vfork() with a call to
fork(), which does not contain a race condition, and eliminates the denial-of-service vulnerability:
vfork function can result in a denial-of-service vulnerability.
|Axivion Bauhaus Suite|
|BADFUNC.VFORK||Use of vfork|
|LDRA tool suite|
Avoid using the 'vfork()' function
|Polyspace Bug Finder|
|CERT C: Rule POS33-C||Checks for use of obsolete standard function (rule fully covered)|
|SonarQube C/C++ Plugin|
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Key here (explains table format and definitions)
|CWE 2.11||CWE-242, Use of inherently dangerous function||2017-07-05: CERT: Rule subset of CWE|
|MITRE CWE||CWE-676||Prior to 2018-01-12:CERT:Relationship Unspecified|
|CWE 3.1||CWE-676, Use of Potentially Dangerous Function||2018-10-18:CERT:None|
CERT-CWE Mapping Notes
Key here for mapping notes
CWE-242 and POS33-C
CWE-242 = Union( POS33-C, list) where list =
- Use of dangerous functions besides vfork
CWE-676 and POS33-C
INTERSECTION(CWE-676, POS33-C) = ∅