Binding read() with threats

During remediation workshops one topic is being brought back every time among programmers: "why should we fix this vulnerability – it’s only read() function, you can’t overwrite anything with it…" Now if you are tired of repeating the same line that just like any other reported problem, every vulnerability should be fixed, than this blog entry is for you. You can show it both to your management and software developers as validity proof of your approach.

First of all: every single vulnerability must be fixed. The end. Secondly it’s not really true that read() and similar calls are not resulting in overwriting anything. Coming down to operating system level there must be file descriptor tables and file I/O buffers just to name a few kernel structures which are getting modified by simple read operation. Additional resources like file system modules , hardware abstraction layer and security module are involved also. They all allocate some resources in order to properly handle read request. So in fact read() is at least triggering some write operations somewhere in underlying operating system. Not to mention possible creation of temporary files to handle large read request. This could lead to race condition.

While using API like ReadFile() from Windows SDK you have to declare buffer size (yes, this can lead to buffer overflow or other boundary condition issues obviously) in languages like Python, the programmer does not have to care about allocating memory for operation like readlines(). Unfortunately the above statement is not exactly true. The knowledgeable Python programmer will first check file size before trying to load it in one operation into memory possibly eating up free resources in case of extremely large files. So read() call can lead to denial-of-service attacks too.

I just love exploiting read() calls in web applications. This gives a lot of possibilities if you can somehow control the name of object being read. While it is harder to spot vulnerability like this: …/read.php?filename=/etc/passwd than 5 years ago, you can still have a lot of fun with insecure read() calls. Sometimes attacker cannot influence object name directly for read operation. However this is not an excuse not to exploit such problem. Even if attacker is not able to change the filename he can still have impact on values being read by read() call. This brings us to another issue: validating both input and output data. Insecure data are not coming only from GET/POST requests. Reading file with data based on supplied form without validating data for example is a vulnerability even if one cannot find a way to exploit it. Lack of exploitation technique in our hands mustn’t be excuse for not fixing vulnerability.

When reviewing source code remember that read()-like calls are hidden beneath API or integral parts of language like import (in Python) or require (in PHP) for example. Such calls can lead to vulnerabilities too.

To recap: read()-like calls can be dangerous. If somebody reports you vulnerability connected with read call just get it fixed just like any other reported problem. If one would like to bind read() calls with vulnerability catalog here is a short, incomplete list:

1. Boundary condition
2. Race condition
3. Input/Output validation
4. Information leak
5. Resource leak or starvation / Denial-of-Service