Intriguing attack name isn’t it? Pronounced as TOCKTOO, this is a time-of-check/time-of-use (TOC/TOU) attack. This deals with the sequence of steps a system uses to complete a task. This type of attack takes advantage of the dependency on the timing of events that take place in a multitasking operating system.
Let’s take some routine day-to-day examples to better understand this concept. Note that these examples are mentioned to help you better understand the concept. Do you love Netflix? Well, I do. When you watch a series on Netflix, you need to authenticate yourself. Let’s break this into 2 steps:
Process 1: Validate your credentials to check your subscription validity.
Process 2: Open up the series for you.
In a TOC TOU attack, the attacker ensures that process 2 is executed before process 1. If you may wonder how can this happen, consider that operating systems and applications are, in reality, just lines and lines of instructions. An operating system must carry out instruction 1, then instruction 2, then instruction 3, and so on. This is how it is written. If an attacker can get in between instructions 2 and 3 and manipulate something, he/she can control the result of these activities.
TOCTOU race conditions are common in Unix between operations on the file system but can occur in other contexts, including local sockets and improper use of database transactions. A TOCTTOU attack exploiting such conditions can lead to privilege escalation, allowing unauthorized access to resources, such as read and write access, as well as avoiding log and audit controls. This sort of attack is difficult to detect. It requires not only looking for evidence but also determining whether it could be caused by TOCTOU.
The root cause of many TOCTTOU vulnerabilities lies in the lack of concurrency control in an operating system's file-system API and so it's not a problem that's easy to resolve. Most OSes change the order that instructions and processes are actually executed to improve efficiency. A programmer has to achieve the atomicity of two operations using an API that isn't designed for such a purpose. Therefore, the challenge is ensuring the file system state, managed by the operating system, cannot change between two system calls.
This type of attack is also referred to as an asynchronous attack. Asynchronous describes a process in which the timing of each step may vary. The attacker gets in between these steps and modifies something. Race conditions are also considered TOC/TOU attacks by some in the industry.
Beginning with Windows Vista, Microsoft added transaction support (TxF) to their NTFS file system. All updates are kept isolated within a transaction until committed when they are atomically published to the rest of the system. Programmers should be aware of the dangers of TOCTTOU vulnerabilities and make use of these recent features to prevent TOCTTOU race conditions or reduce their potential impact.
In comparison, a race condition is when two different processes need to carry out their tasks on one resource. A very simple example would be to understand via the BODMAS technique of mathematics.
Example 1: 3*5+10
Process 1: Multiplication
Process 2: Addition
Ideally, process 1 needs to be performed because the multiplication of numbers takes precedence over addition. The result is 25.
However, if process 2 takes place first, the result will be different.
Look at this issue from a security perspective, if authentication and authorization are two steps that need to be performed step by step, the race condition may actually process authorization before the authentication and an unauthorized user may access the information. These two attacks may appear to be similar but are actually different.
To avoid TOC/TOU attacks, it is best if the operating system can apply software locks to the items it will use when it is carrying out its “checking” tasks. So if a user requests access to a file, while the system is validating this user’s authorization, it should put a software lock on the file being requested.
Comments ()