1706
cases in which self-modifying code is required. Finally, an attack could still cause a denial of
service, since the typical response is to exit the application.
Phase: Architecture and Design
Phase: Operation
Strategy = Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks
[REF-76]. If possible, create isolated accounts with limited privileges that are only used for a
single task. That way, a successful attack will not immediately give the attacker access to the
rest of the product or its environment. For example, database applications rarely need to run as
the database administrator, especially in day-to-day operations.
Phase: Architecture and Design
Phase: Operation
Strategy = Sandbox or Jail
Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between
the process and the operating system. This may effectively restrict which files can be accessed
in a particular directory or which commands can be executed by the software. OS-level examples
include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide
some protection. For example, java.io.FilePermission in the Java SecurityManager allows the
software to specify restrictions on file operations. This may not be a feasible solution, and it
only limits the impact to the operating system; the rest of the application may still be subject to
compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.
Effectiveness = Limited
The effectiveness of this mitigation depends on the prevention capabilities of the specific
sandbox or jail being used and might only help to reduce the scope of an attack, such as
restricting the attacker to certain system calls or limiting the portion of the file system that can be
accessed.
Demonstrative Examples
Example 1:
This example takes an IP address from a user, verifies that it is well formed and then looks up the
hostname and copies it into a buffer.
Example Language: C (Bad)
void host_lookup(char *user_supplied_addr){
struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);
/*routine that ensures user_supplied_addr is in the right format for conversion */
validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);
}
This function allocates a buffer of 64 bytes to store the hostname under the assumption that the
maximum length value of hostname is 64 bytes, however there is no guarantee that the hostname
will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large
hostname, then the function may overwrite sensitive data or even relinquish control flow to the
attacker.
Note that this example also contains an unchecked return value (CWE-252) that can lead to a
NULL pointer dereference (CWE-476).
CWE Version 4.14
CWE-805: Buffer Access with Incorrect Length Value
CWE-805: Buffer Access with Incorrect Length Value