Need

Proper resource management and deallocation

Context

• Usage of Dart for building cross-platform mobile, web, and desktop applications
• Usage of Shelf for managing data models and database operations

Description

Non compliant code

        import 'package:shelf/shelf.dart' as shelf;

Future inboundOutboundFlowHandler(shelf.Request request) async {
  var connection = await Connection.open();

  var inboundFlow = await connection.getInboundFlow();
  var outboundFlow = await connection.getOutboundFlow();

  // processing inbound and outbound flows...

  // Missing closing connections

  return shelf.Response.ok('Processed successfully');
}
        
        

In the above code snippet, we have a function inboundOutboundFlowHandler which is a request handler for a certain route in a backend application using the shelf framework in Dart.

The handler opens a connection, gets the inbound and outbound flows, processes them, and then sends a response back to the client.

The vulnerability lies in the fact that the opened connection and the obtained inbound and outbound flows are not closed after they have been processed. This can lead to a memory leak as the resources allocated for these flows are not released back to the system.

In a high traffic scenario, this can quickly exhaust the available system resources leading to degraded performance or even system crashes. This is a typical example of improper resource allocation or management, a common vulnerability in software applications.

Steps

• Identify the resources that need to be released. In this case, it's the 'connection', 'inboundFlow', and 'outboundFlow'.
• Ensure that these resources are closed after their use. This can be done by calling the 'close' method on these objects.
• Implement a 'finally' block in your code. This block will always be executed, regardless of whether an exception was thrown or not. This is the ideal place to release resources.
• In the 'finally' block, close the 'inboundFlow', 'outboundFlow', and 'connection'.
• Ensure that the 'close' methods are called in the correct order. Resources should be released in the reverse order of their acquisition. In this case, first close 'inboundFlow', then 'outboundFlow', and finally 'connection'.
• Test your code to ensure that resources are being released properly. Monitor your system's resource usage before and after the fix to confirm that the memory leak has been resolved.

Compliant code

        import 'package:shelf/shelf.dart' as shelf;

Future inboundOutboundFlowHandler(shelf.Request request) async {
  Connection connection;
  InboundFlow inboundFlow;
  OutboundFlow outboundFlow;

  try {
    connection = await Connection.open();

    inboundFlow = await connection.getInboundFlow();
    outboundFlow = await connection.getOutboundFlow();

    // processing inbound and outbound flows...

  } finally {
    // Close the resources in the reverse order of their acquisition
    if (inboundFlow != null) {
      await inboundFlow.close();
    }

    if (outboundFlow != null) {
      await outboundFlow.close();
    }

    if (connection != null) {
      await connection.close();
    }
  }

  return shelf.Response.ok('Processed successfully');
}
        
        

The updated code now includes a try/finally block. This ensures that the resources are always released, regardless of whether an exception was thrown or not.

In the try block, we open the connection and get the inbound and outbound flows. These operations might throw exceptions, but since they are inside a try block, any exception will cause the control to immediately move to the finally block.

In the finally block, we close the inboundFlow, outboundFlow, and connection in the reverse order of their acquisition. This is a good practice to follow when releasing resources.

Before closing each resource, we check if it is null. This is because if an exception was thrown before a resource was initialized, it will be null, and calling close on a null object will throw a NullPointerException.

This updated code ensures that all resources are properly released, thus fixing the memory leak vulnerability.

References

• 317. Improper resource allocation - Memory leak