Programming Homework Help

11268 Resource leak

The system resource will not be reclaimed and reused, reducing the future availability of the resource.

In code: Leak of a system resource (CWE-404)

We have production applications that go through security checks. Often this checks throw security issues within the code.

For issue type, need a document which explains about resource leak in source code and how it can affect the application.

Also, need real code examples that can walk through the steps to remediate or fix this issue. Code is not language specific, but one example per one language is fine. You can review CWE issues and come up with a remediation plan for this issue.

________________________________________************************_______________________________________

Below is the sample that I made for other type of issue:

Dereference null return value

All but the most simple web applications have to include local resources, such as images, themes, other scripts, and so on. Every time a resource or file is included by the application, there is a risk that an attacker may be able to include a file or remote resource you didn’t authorize.

The software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted path.

Overview

Many file operations are intended to take place within a restricted directory. By using special elements such as “..” and “/” separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the “../” sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as “/usr/local/bin”, which may also be useful in accessing unexpected files. This is referred to as absolute path traversal.

In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to widen the scope of attack. For example, the software may add “.txt” to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.

Issues

The following sections review some of the more common Filesystem path, filename, or URI manipulation vulnerabilities with suggestions for mitigation.

Example 1

In the model underneath, the path to a dictionary file is read from a system property and used to initialize a File object.

Example Language: Java

However, the path is not validated or modified to prevent it from containing relative or absolute path sequences before creating the File object. This allows anyone who can control the system property to determine what file is used. Ideally, the path should be resolved relative to some kind of application or user home directory.

Example 2

The following code attempts to validate a given input path by checking it against a whitelist and once validated delete the given file. In this specific case, the path is considered valid if it starts with the string “/safe_dir/”.

Example Language: Java

An attacker could provide an input such as this:

/safe_dir/../important.dat

The software assumes that the path is valid because it starts with the “/safe_path/” sequence, but the “../” sequence will cause the program to delete the important.dat file in the parent directory.

Example 3

This vulnerability shows up if the both of the following are true:

• The malicious user can enter a path to a file system object that would be accessed;
• After giving the path to the object, the malicious user can perform tasks, previously limited to him. Let’s take a look at an example, where the application receives a file name from and HTTP request, checks for its existence on the server, and returns the file to the user in an HTTP response:

Example Language: Java

Let’s suppose the HTML page that asks the user to download the file presents a list of available files, thus limiting the user’s access to the files on the server. However, the malicious user can create URL in the browser address bar himself, giving the path to the file he needs. Thus, the user can gain access to server files that are not meant for the public.

Potential consequences

1. The malicious user can gain unsanctioned access to confidential data stored on the file system;
2. The malicious user can gain write access to critical files, including config files. For example, he can write in a new user account, and bypass authorization;
3. The malicious user can write access to executable files and libraries. He can thus replace a critical application module for his own, gaining complete system access;
4. The malicious user can gain erase access to critical files, destroying system productivity.

Removal recommendations/Remediations

• The most effective way to prevent file path traversal vulnerabilities is to avoid passing user-supplied input to filesystem APIs altogether. Many application functions that do this can be rewritten to deliver the same behavior in a safer way.
• When performing any input filtration on the client side, make sure that similar filtration is done on the server side as well. This is done because the user can modify the data after the client-side filtering is done;
• Assume that all data coming from the client is a potential threat, including hidden form fields and cookies. We recommend using the “accept known good” method for input filtration, such as using a whitelist that describes acceptable input format. All input that does not follow the format, described in the whitelist should be rejected. You can, for example, limit file extensions, allowed symbols in the input string or file name length in symbols:
• To ensure the validity of file system paths, you can use a list of allowed symbols. For example, add a limitation that the file must contain only ‘.’ symbol, and no ‘/’ symbols. We recommend against relying on blacklists that include potentially dangerous symbols.
• 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 whitelist validation schemes by introducing dangerous inputs after they have been checked.
• Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
• Store library include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server’s access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately.
• Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth.
• 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 software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

If it is considered unavoidable to pass user-supplied input to filesystem APIs, then two layers of defense should be used together to prevent attacks:

The application should validate the user input before processing it. Ideally, the validation should compare against a whitelist of permitted values. If that isn’t possible for the required functionality, then the validation should verify that the input contains only permitted content, such as purely alphanumeric characters.

After validating the supplied input, the application should append the input to the base directory and use a platform filesystem API to canonicalize the path. It should verify that the canonicalized path starts with the expected base directory.

Below is an example of some simple Java code to validate the canonical path of a file based on user input:

• Before validation filesystem paths, canonize them

For example, this includes filters that remove dangerous sequences from the string. If the filter removes ‘../’ from the string, then after filtering the sequence ‘../…//’, the result would be ‘../’, just what the malicious user needs. Using these recommendations, we can rewrite the first example using the validateFilename function:

Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes “..” sequences and symbolic links (CWE-23, CWE-59). This includes:

• realpath() in C
• getCanonicalPath() in Java
• GetFullPath() in ASP.NET
• realpath() or abs_path() in Perl
• realpath() in PHP

This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.

Note: An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.

Further reading

http://cwe.mitre.org/data/definitions/22.html

https://www.owasp.org/index.php/File_System#Path_traversal

https://portswigger.net/web-security/file-path-traversal