While it is executing, the software sets the permissions of an object in a way that violates the intended permissions that have been specified by the user.
The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize “..” sequences that can resolve to a location that is outside of that directory.
Confidentiality, Integrity: Read Files or Directories, Modify Files or Directories
Potential Mitigations
Phase: Implementation
Description:
Phase: Implementation
Description:
Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize “../” sequences that can resolve to a location that is outside of that directory.
Confidentiality, Integrity: Read Files or Directories, Modify Files or Directories
Potential Mitigations
Phase: Implementation
Description:
Phase: Implementation
Description:
Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
The software does not handle or incorrectly handles when a particular element is not the expected type, e.g. it expects a digit (0-9) but is provided with a letter (A-Z).
Integrity, Other: Varies by Context, Unexpected State
Potential Mitigations
Phase: Implementation
Description:
Phase: Implementation
Description:
Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
The program calls a function that can never be guaranteed to work safely.
Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account. The gets() function is unsafe because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to gets() and overflow the destination buffer. Similarly, the >> operator is unsafe to use when reading into a statically-allocated character array because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to the >> operator and overflow the destination buffer.
The program uses the chroot() system call to create a jail, but does not change the working directory afterward. This does not prevent access to files outside of the jail.
Improper use of chroot() may allow attackers to escape from the chroot jail. The chroot() function call does not change the process’s current working directory, so relative paths may still refer to file system resources outside of the chroot jail after chroot() has been called.
The chroot() system call allows a process to change its perception of the root directory of the file system. After properly invoking chroot(), a process cannot access any files outside the directory tree defined by the new root directory. Such an environment is called a chroot jail and is commonly used to prevent the possibility that a processes could be subverted and used to access unauthorized files. For instance, many FTP servers run in chroot jails to prevent an attacker who discovers a new vulnerability in the server from being able to download the password file or other sensitive files on the system.
Using realloc() to resize buffers that store sensitive information can leave the sensitive information exposed to attack, because it is not removed from memory.
When sensitive data such as a password or an encryption key is not removed from memory, it could be exposed to an attacker using a “heap inspection” attack that reads the sensitive data using memory dumps or other methods. The realloc() function is commonly used to increase the size of a block of allocated memory. This operation often requires copying the contents of the old memory block into a new and larger block. This operation leaves the contents of the original block intact but inaccessible to the program, preventing the program from being able to scrub sensitive data from memory. If an attacker can later examine the contents of a memory dump, the sensitive data could be exposed.
Be careful using vfork() and fork() in security sensitive code. The process state will not be cleaned up and will contain traces of data from past use.
The J2EE application directly manages connections, instead of using the container’s connection management facilities.
The J2EE standard forbids the direct management of connections. It requires that applications use the container’s resource management facilities to obtain connections to resources. Every major web application container provides pooled database connection management as part of its resource management framework. Duplicating this functionality in an application is difficult and error prone, which is part of the reason it is forbidden under the J2EE standard.