Software Testing Blog

Looking under the hood of a DoS attack

Last week, I shared some thoughts on the on-going “cyber war” involving WikiLeaks and some financial organizations in aComputer Weekly post  as a guest blogger. As the WikiLeaks saga continues, with all the attention on Bank of America this week,  let’s dig a little deeper to see how software code plays a role in the much publicized Denial of Service (DoS) attacks.

Under the broad umbrella of Denial of Service vulnerabilities are program errors like attempting to write to a memory region out of bounds, a resource leak such as socket connections or memory, a program crash or an infinite loop. And these errors are nothing but manifestations of code defects like null pointer dereferences, attempted use of freed memory, leak of memory or system resource, out of bounds write or use of uninitialized variables.

Take a look at the following simple example in Java.

// Returns newly allocated socket resource
public Socket socket_return() throws UnknownHostException, IOException {

Socket s = new Socket(“nothing”, 128);

return s;


// Called every time a connection is made.
public void socket_per_connection() throws UnknownHostException, IOException {

Socket s = socket_return();

// returns without freeing resource

It’s a highly stylized example, though I have seen similar code in an FTP server code base. The idea is that the socket_per_connection() function is called every time a connection request is received. Once this function executes, an authentication logic verifies the validity of the connecting user. If it’s not a valid user, the connection is dropped. Unfortunately, because socket_per_connection() is leaking a socket each time a connection request is made, regardless of whether the user is valid or malicious, very soon we get to a point where the socket_return() function cannot allocate new sockets and even valid users cannot connect to our server.

Looking at that piece of code in isolation might make it seem fairly harmless. It is a simple resource leak defect. But when put in context of the logic of the program, we can see its impact as much larger that might quickly bring our server to its knees if an attacker decides to make continuous connection requests. A null pointer dereference, or an infinite loop defect in the connection logic can similarly lead to a denial of service vulnerability.

It is not surprising that DoS attacks are fairly prevalent on Internet services like HTTP, DHCP, FTP, SSH, etc. These software services are accessible to a remote client, and process all incoming connection requests in most cases to make a decision on whether to process the requests any further or terminate the connection. Just a few days ago, US-CERT  issued a vulnerability note  for the ISC DHCP server for a denial of service exploit where an unauthenticated remote attacker can make the server unresponsive by simply making a TCP connection on any port configured for communication with a peer.

News events like the WikiLeaks saga are good reminders that software does not always do what we expect from it. Though if we look deeper, there is a strong chance that the underlying code defect that resulted in that unexpected behavior can be found, analyzed and fixed.

Leave a Reply

Your email address will not be published. Required fields are marked *