Skip to main content

Improper resource allocation - Memory leak

Need​

Proper management of resources to prevent memory leaks

Context​

  • Usage of Java for building cross-platform applications
  • Usage of javax.servlet for building Java web applications with servlets

Description​

Non compliant code​

import javax.servlet.*;
import javax.servlet.http.*;

public class VulnerableServlet extends HttpServlet {

    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        InputStream is = req.getInputStream();
        // handling the input stream
        // ...
        // No call to is.close() here
    }
}

The above code demonstrates a servlet that handles POST requests. It reads the request's input stream but does not properly close the stream after use. This is a typical example of a memory leak.

In Java, when a stream is opened, it occupies a certain amount of system resources (like memory). These resources are not infinite and should be managed properly. If a stream is not closed after its use, the resources it occupies are not released back to the system. This is known as a memory leak.

In the long run, if the application continues to open streams without closing them, the system may eventually run out of resources and become unresponsive or crash. This is why it's important to always close streams after use.

In the context of a servlet, this can be especially problematic. Servlets are typically long-running and handle many requests. If each request results in a memory leak, the servlet container (and by extension, the whole server) can run out of resources quite quickly.

In this specific code, the InputStream is is opened to read the request data, but it is never closed. This means that the memory allocated for this stream is never released, leading to a memory leak.

Steps​

  • Use try-with-resources or finally block to ensure proper resource cleanup.
  • Close the input stream after handling the data.
  • Consider using a buffer to read the input stream and close the buffer after use.
  • Avoid unnecessary resource allocation by using efficient data handling techniques.
  • Regularly review and refactor the code to identify and fix any potential resource leaks.

Compliant code​

import javax.servlet.*;
import javax.servlet.http.*;
import java.io.IOException;
import java.io.InputStream;

public class FixedServlet extends HttpServlet {

    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        try (InputStream is = req.getInputStream()) {
            // handling the input stream
            // ...
        } catch (IOException e) {
            // handle exception
        }
    }
}

The fixed code uses the try-with-resources statement, which is a try statement that declares one or more resources. A resource is an object that must be closed after the program is finished with it. The try-with-resources statement ensures that each resource is closed at the end of the statement. This would be equivalent to using a finally block and explicitly closing the resource, but it's more concise and less error-prone.

In the original code, the InputStream is was not being closed, which could lead to a memory leak if the doPost method is called multiple times, as each call would allocate a new InputStream without releasing the previous one.

In the fixed code, the InputStream is is declared within the try-with-resources statement, so it will be automatically closed when the try block is exited, either normally or via an exception. This ensures that the system resources allocated for the InputStream are properly released, preventing a memory leak.

The catch block is used to handle any IOException that might be thrown when trying to get the input stream or when trying to close it. The specific handling would depend on the requirements of your application.

This fix also follows the principle of least privilege by only keeping the resource open for the minimum amount of time necessary, reducing the window of opportunity for an attacker to exploit the open resource.

References​

Last updated on