Most successful attacks begin with a violation of the programmer's assumptions. By accepting an XML document without validating it against a DTD or XML schema, the programmer leaves a door open for attackers to provide unexpected, unreasonable, or malicious input. It is not possible for an XML parser to validate all aspects of a document's content; a parser cannot understand the complete semantics of the data. However, a parser can do a complete and thorough job of checking the document's structure and therefore guarantee to the code that processes the document that the content is well-formed.

NoSQL injection vulnerabilities in DynamoDB can occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a DynamoDB query.

Example 1: The following code dynamically constructs and executes a DynamoDB query that searches for a user given their email address or username, along with their password.

    ...
        // "type" parameter expected to be either: "Email" or "Username"
        string type = request["type"];
        string value = request["value"];
        string password = request["password"];
        
        var ddb = new AmazonDynamoDBClient();
    
        var attrValues = new Dictionary<string,AttributeValue>();
        attrValues[":value"] = new AttributeValue(value);
        attrValues[":password"] = new AttributeValue(password);
    
        var scanRequest = new ScanRequest();
        scanRequest.FilterExpression = type + " = :value AND Password = :password";
        scanRequest.TableName = "users";
        scanRequest.ExpressionAttributeValues = attrValues;
    
        var scanResponse = await ddb.ScanAsync(scanRequest);
    ...
    

The query intends to execute the following code:

Email = :value AND Password = :password

or

Username = :value AND Password = :password

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if type only contains any of the expected values. If an attacker provides a type value such as :value = :value OR :value, then the query becomes the following:

:value = :value OR :value = :value AND Password = :password

The addition of the :value = :value condition causes the where clause to always evaluate to true, so the query returns all entries stored in the users collection, regardless of the email owner.

NoSQL injection in MongoDB errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a MongoDB query.

Example 1: The following code dynamically constructs and executes a MongoDB query that searches for an email with a specific ID.

...
    String userName = User.Identity.Name;
    String emailId = request["emailId"];
    var coll = mongoClient.GetDatabase("MyDB").GetCollection<BsonDocument>("emails");
    var docs = coll.Find(new BsonDocument("$where", "this.name == '" + name + "'")).ToList();
...

The query intends to execute the following code:

    this.owner == "<userName>" && this.emailId == "<emailId>"

However, because the query is constructed dynamically by concatenating a constant query string and user input, the query only behaves correctly if emailId does not contain a single-quote character. If an attacker with the user name wiley enters the string "123' || '4' != '5" for emailId, then the query becomes the following:

    this.owner == 'wiley' && this.emailId == '123' || '4' != '5'

The addition of the || '4' != '5' condition causes the where clause to always evaluate to true, so the query returns all entries stored in the emails collection, regardless of the email owner.

NoSQL injection in MongoDB errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a MongoDB query.

Example 1: The following code dynamically constructs and executes a MongoDB query that searches for an email with a specific ID.

...
    userName = req.field('userName')
    emailId = req.field('emaiId')
    results = db.emails.find({"$where", "this.owner == \"" + userName + "\" && this.emailId == \"" + emailId + "\""});
...

The query intends to execute the following code:

    this.owner == "<userName>" && this.emailId == "<emailId>"

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if emailId does not contain a double-quote character. If an attacker with the user name wiley enters the string 123" || "4" != "5 for emailId, then the query becomes the following:

    this.owner == "wiley" && this.emailId == "123" || "4" != "5"

The addition of the || "4" != "5" condition causes the where clause to always evaluate to true, so the query returns all entries stored in the emails collection, regardless of the email owner.

Null-pointer errors are usually the result of one or more programmer assumptions being violated.

Most null-pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null-pointer dereference, the attacker may be able to use the resulting exception to bypass security logic or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Example 1: In the following code, the programmer assumes that the system always has a property named "cmd" defined. If an attacker can control the program's environment so that "cmd" is not defined, the program throws a null-pointer exception when it attempts to call the Trim() method.

string cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();

Null-pointer exceptions usually occur when one or more of the programmer's assumptions is violated. There are at least three flavors of this problem: check-after-dereference, dereference-after-check, and dereference-after-store. A check-after-dereference error occurs when a program dereferences a pointer that can be null before checking if the pointer is null. Dereference-after-check errors occur when a program makes an explicit check for null, but proceeds to dereference the pointer when it is known to be null. Errors of this type are often the result of a typo or programmer oversight. A dereference-after-store error occurs when a program explicitly sets a pointer to null and dereferences it later. This error is often the result of a programmer initializing a variable to null when it is declared.

Most null-pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null-pointer dereference, the attacker may be able to use the resulting exception to bypass security logic in order to mount a denial of service attack, or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Example 1: In the following code, the programmer assumes that the variable ptr is not NULL. That assumption is made explicit when the programmer dereferences the pointer. This assumption is later contradicted when the programmer checks ptr against NULL. If ptr can be NULL when it is checked in the if statement then it can also be NULL when it dereferenced and may cause a segmentation fault.

ptr->field = val;
...
if (ptr != NULL) {
	...
}

Example 2: In the following code, the programmer confirms that the variable ptr is NULL and subsequently dereferences it erroneously. If ptr is NULL when it is checked in the if statement, then a null dereference will occur, thereby causing a segmentation fault.

if (ptr == null) {
        ptr->field = val;
        ...
}

Example 3: In the following code, the programmer forgets that the string '\0' is actually 0 or NULL, thereby dereferencing a null-pointer and causing a segmentation fault.

if (ptr == '\0') {
        *ptr = val;
        ...
}

Example 4: In the following code, the programmer explicitly sets the variable ptr to NULL. Later, the programmer dereferences ptr before checking the object for a null value.

*ptr = NULL;
...
ptr->field = val;
...
}

In general as programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations

Statements that are removed from a language are usually replaced by newer counterparts that perform the same task in somewhat different and hopefully better way.

In particular, SAP ABAP evolved to include ABAP Objects - the object oriented extension of ABAP and to operate in a Unicode compatible environment. As a result, stricter syntax is enforced in classes or in Unicode programs. Obsolete constructs are still available only for reasons of compatibility with older releases and they can only be used outside of classes or in non-Unicode programs. There are replacement constructions for all obsolete language elements, which improve the efficiency and readability of programs. Many implicit, ambiguous type/length/memory specifications in the obsolete syntax are required to be specified in a more precise and explicit way in the newer syntax. It is recommended to adopt the newer syntax to make programs easier to understand, more robust and easier to maintain.


Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, functions occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations


Functions that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.
Example: The following code constructs a new SqlClientPermission object, which regulates how users are allowed to connect to a database. In this example, the program passes false as the second parameter to the constructor, which controls whether users are allowed to connect with blank passwords. Passing false to this parameter indicates that blank passwords should not be allowed.

...
SCP = new SqlClientPermission(pstate, false);
...

However, because the PermissionState object passed as the first parameter supersedes any value passed to the second parameter, the constructor allows blank passwords for database connections, which contradicts the second argument. To disallow blank passwords, the program should pass PermissionState.None to the first parameter of the constructor. Because of the ambiguity in its functionality, the two-parameter version of the SqlClientPermission constructor has been deprecated in favor of the single parameter version, which conveys the same degree of information without the risk of misinterpretation.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, functions occasionally become obsolete due to:

- Advances in the language.
- Improved understanding of how operations should be performed effectively and securely.
- Changes in the conventions that govern certain operations.

Functions that are removed are usually replaced by newer counterparts that perform the same task in some different and hopefully improved way.
Example: The following code uses the deprecated function getpw() to verify that a plain text password matches a user's encrypted password. If the password is valid, the function sets result to 1; otherwise it is set to 0.

	...
	getpw(uid, pwdline);
	for (i=0; i<3; i++){
	cryptpw=strtok(pwdline, ":");
		pwdline=0;
	}
result = strcmp(crypt(plainpw,cryptpw), cryptpw) == 0;
	...

Although the code often behaves correctly, using the getpw() function can be problematic from a security standpoint, because it can overflow the buffer passed to its second parameter. Because of this vulnerability, getpw() has been supplanted by getpwuid(), which performs the same lookup as getpw() but returns a pointer to a statically-allocated structure to mitigate the risk.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations

Methods that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.


Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

As programming languages evolve, methods occasionally become obsolete due to:

- Advances in the language
- Improved understanding of how operations should perform effectively and
securely
- Changes in the conventions that govern certain operations.

Methods that are removed from a language are usually replaced by newer counterparts that perform the same task in some different and hopefully better way.
Example: The following code uses the Digest::HMAC stdlib, which use of is explicitly discouraged in the documentation due to accidental involvement within a release.

require 'digest/hmac'

hmac = Digest::HMAC.new("foo", Digest::RMD160)
...
hmac.update(buf)
...

In this example the Digest::HMAC class was deprecated immediately upon involvement due to accidental inclusion within a release. Due to possibility of this not working as expected because of experimental and not properly tested code, use of this is highly discouraged, especially considering the relation HMACs have in relation to cryptographic functionality.

Not all functions are deprecated or replaced because they pose a security risk. However, the presence of an obsolete function often indicates that the surrounding code has been neglected and may be in a state of disrepair. Software security has not been a priority, or even a consideration, for very long. If the program uses deprecated or obsolete functions, it raises the probability that there are security problems lurking nearby.

Due to the fast-paced nature of smart contracts, functions and operators may become deprecated with newer compiler versions and using them may lead to low quality code, unintended side effects and/or compilation errors.

Example 1: The following code obtains the hash of the current block using block.blockhash(), which has been deprecated since version 0.5.0 of the Solidity compiler.

bytes32 blockhash = block.blockhash(0);

Many DNS servers are susceptible to spoofing attacks, so you should assume that your software will someday run in an environment with a compromised DNS server. If attackers are allowed to make DNS updates (sometimes called DNS cache poisoning), they can route your network traffic through their machines or make it appear as if their IP addresses are part of your domain. Do not base the security of your system on DNS names.
Example: The following code sample uses a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.

 IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
 IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
 if (hostInfo.HostName.EndsWith("trustme.com")) {
   trusted = true;
 }

IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers may easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.

The getlogin() function is supposed to return a string containing the name of the user currently logged in at the terminal, but an attacker may cause getlogin() to return the name of any user logged in to the machine. Do not rely on the name returned by getlogin() when making security decisions.
Example 1: The following code relies on getlogin() to determine whether or not a user is trusted. It is easily subverted.

 pwd = getpwnam(getlogin());
 if (isTrustedGroup(pwd->pw_gid)) {
 allow();
 } else {
 deny();
 }

Regardless of the language a program is written in, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. The GetChars method in Decoder & Encoding classes and the GetBytes method in Encoder & Encoding classes in the .NET Framework internally performs pointer arithmetic on the char & byte arrays to convert range of character into range of bytes and vice versa.
When performing pointer arithmetic operations, developers often override the preceding methods in a bad fashion and introduce vulnerabilities such as arbitrary code execution, application logic abuse and denial of service.

When character sets are mismatched between the operating system and applications running on the operating system, unsupported characters passed to default API methods can be best-fit mapped to dangerous characters.

Example 1: In Objective-C, the following example converts an NSString object containing a UTF-8 character to ASCII data then back:

...
unichar ellipsis = 0x2026;
NSString *myString = [NSString stringWithFormat:@"My Test String%C", ellipsis];
NSData *asciiData = [myString dataUsingEncoding:NSASCIIStringEncoding allowLossyConversion:YES];
NSString *asciiString = [[NSString alloc] initWithData:asciiData encoding:NSASCIIStringEncoding];
NSLog(@"Original: %@ (length %d)", myString, [myString length]);
NSLog(@"Best-fit-mapped: %@ (length %d)", asciiString, [asciiString length]);
// output:
// Original: My Test String... (length 15)
// Best-fit-mapped: My Test String... (length 17)
...

If you look at the output carefully, the "..." character was translated to three consecutive periods. If you had sized your output buffer based on the input buffer your application could be vulnerable to buffer overflow. Other characters can get mapped from one character to two. The Greek "fi" character will get mapped to an "f" followed by an "i". By front loading the buffer with these characters an attacker gains complete control over the number of characters used to overflow the buffer.

When character sets are mismatched between the operating system and applications running on the operating system, unsupported characters passed to default API methods can be best-fit mapped to dangerous characters.

Example 1: In Swift, the following example converts an NSString object containing a UTF-8 character to ASCII data then back:

...
let ellipsis = 0x2026;
let myString = NSString(format:"My Test String %C", ellipsis)
let asciiData = myString.dataUsingEncoding(NSASCIIStringEncoding, allowLossyConversion:true)
let asciiString = NSString(data:asciiData!, encoding:NSASCIIStringEncoding)
NSLog("Original: %@ (length %d)", myString, myString.length)
NSLog("Best-fit-mapped: %@ (length %d)", asciiString!, asciiString!.length)

// output:
// Original: My Test String ... (length 16)
// Best-fit-mapped: My Test String ... (length 18)
...

If you look at the output carefully, the "..." character was translated to three consecutive periods. If you had sized your output buffer based on the input buffer your application could be vulnerable to buffer overflow. Other characters can get mapped from one character to two. The Greek "fi" character will get mapped to an "f" followed by an "i". By front loading the buffer with these characters an attacker gains complete control over the number of characters used to overflow the buffer.

Windows provides a large number of utility functions that manipulate buffers containing filenames. In most cases, the result is returned in a buffer that is passed in as input. (Usually the filename is modified in place.) Most functions require the buffer to be at least MAX_PATH bytes in length, but you should check the documentation for each function individually. If the buffer is not large enough to store the result of the manipulation, a buffer overflow can occur.

Example:

char *createOutputDirectory(char *name) {
	char outputDirectoryName[128];
	if (getCurrentDirectory(128, outputDirectoryName) == 0) {
		return null;
	}
	if (!PathAppend(outputDirectoryName, "output")) {
		return null;
	}
	if (!PathAppend(outputDirectoryName, name)) {
		return null;
	}
	if (SHCreateDirectoryEx(NULL, outputDirectoryName, NULL)
        != ERROR_SUCCESS) {
		return null;
	}
	return StrDup(outputDirectoryName);
}

In this example the function creates a directory named "output\<name>" in the current directory and returns a heap-allocated copy of its name. For most values of the current directory and the name parameter, this function will work properly. However, if the name parameter is particularly long, then the second call to PathAppend() could overflow the outputDirectoryName buffer, which is smaller than MAX_PATH bytes.

Certain identified functions are known to blindly follow symbolic links. When this happens, your application will open, read, or write data to the file that the symbolic link points to instead of the representation of the symbolic link. An attacker may fool the application into writing to alternate or critical system files or provide compromised data to the application.

Example 1: The following code utilizes functions which follow symbolic links:

...
	struct stat output;
	int ret = stat(aFilePath, &output);
	// error handling omitted for this example
	struct timespec accessTime = output.st_atime;
...

The umask() man page begins with the false statement:

"umask sets the umask to mask & 0777"

Although this behavior would better align with the usage of chmod(), where the user provided argument specifies the bits to enable on the specified file, the behavior of umask() is in fact opposite: umask() sets the umask to ~mask & 0777.

The umask() man page goes on to describe the correct usage of umask():

"The umask is used to set initial file permissions on a newly-created file. Specifically, permissions in the umask are turned off from the mode argument (so, for example, the common umask default value of 022 results in new files being created with permissions 0666 & ~022 = 0644 = rw-r--r-- in the usual case where the mode is specified as 0666)."

Many APIs will minimize the risk of data loss by completely writing to a temporary file, then copy the complete file to the target destination. Make sure the identified method does not work on files or paths in public or temporary directories as an attacker may replace the temporary file the instant before it is written to the targeted file. This allows the attacker to control the content of files used by the application in public directories.

Example 1: The following code writes the active transactionId to a temporary file in the application Documents directory using a vulnerable method:

...
//get the documents directory:
let documentsPath = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true)[0]
//make a file name to write the data to using the documents directory:
let fileName = NSString(format:"%@/tmp_activeTrans.txt", documentsPath)
// write data to the file
let transactionId = "TransactionId=12341234"
transactionId.writeToFile(fileName, atomically:true)
...

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to a code interpreter (e.g. JSP/ASPX/PHP), then they can cause malicious code contained in these files to execute on the server.

The following code receives an uploaded file and assigns it to the posted object. FileUpload is of type System.Web.UI.HtmlControls.HtmlInputFile.
Example:

HttpPostedFile posted = FileUpload.PostedFile;

Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or dangerous file inclusion vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to the PHP interpreter, then they can cause malicious code contained in these files to execute on the server.

Example 1: The following code processes uploaded files and moves them into a directory under the Web root. Attackers may upload malicious PHP source files to this program and subsequently request them from the server, which will cause them to be executed by the PHP interpreter.

<?php
$udir = 'upload/'; // Relative path under Web root
$ufile = $udir . basename($_FILES['userfile']['name']);
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $ufile)) {
    echo "Valid upload received\n";
} else {
    echo "Invalid upload rejected\n";
} ?>

Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to the Python interpreter, then they can cause malicious code contained in these files to execute on the server.

Example 1: The following code processes uploaded files and moves them into a directory under the web root. Attackers may upload malicious files to this program and subsequently request them from the server.

from django.core.files.storage import default_storage
from django.core.files.base import File
...
def handle_upload(request):
  files = request.FILES
  for f in files.values():
    path = default_storage.save('upload/', File(f))
...

Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a publicly executable directory, then they can cause malicious code contained in these files to execute on the server.

Even if a program stores uploaded files under a directory that isn't publicly accessible, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or remote include vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

Regardless of the language in which a program is written, the most devastating attacks often involve remote code execution, whereby an attacker succeeds in executing malicious code in the program's context. If attackers are allowed to upload files to a directory that is accessible from the Web and cause these files to be passed to a code interpreter (e.g. JSP/ASPX/PHP), then they can cause malicious code contained in these files to execute on the server.
Even if a program stores uploaded files under a directory that isn't accessible from the Web, attackers might still be able to leverage the ability to introduce malicious content into the server environment to mount other attacks. If the program is susceptible to path manipulation, command injection, or dangerous file inclusion vulnerabilities, then an attacker might upload a file with malicious content and cause the program to read or execute it by exploiting another vulnerability.

An <input> tag of type file indicates the program accepts file uploads.
Example:

<input type="file">

Programs that run with root privileges have caused innumerable Unix security disasters. It is imperative that you carefully review privileged programs for all kinds of security problems, but it is equally important that privileged programs drop back to an unprivileged state as quickly as possible in order to limit the amount of damage that an overlooked vulnerability might be able to cause.


Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another.

Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges. An attacker may be able to leverage these elevated privileges to do further damage.

Programs that run with root privileges have caused innumerable Unix security disasters. It is imperative that you carefully review privileged programs for all kinds of security problems, but it is equally important that privileged programs drop back to an unprivileged state as quickly as possible in order to limit the amount of damage that an overlooked vulnerability might cause.


Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another.

Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges. An attacker might be able to leverage these elevated privileges to do further damage.

Programs that run with root privileges have caused innumerable Unix security disasters. It is imperative that you carefully review privileged programs for all kinds of security problems, but it is equally important that privileged programs drop back to an unprivileged state as quickly as possible in order to limit the amount of damage that an overlooked vulnerability might be able to cause.


Privilege management functions can behave in some less-than-obvious ways, and they have different quirks on different platforms. These inconsistencies are particularly pronounced if you are transitioning from one non-root user to another.

Signal handlers and spawned processes run at the privilege of the owning process, so if a process is running as root when a signal fires or a sub-process is executed, the signal handler or sub-process will operate with root privileges. An attacker may be able to leverage these elevated privileges to do further damage.