2.3 Memory Injections & Buffer Overflows & Race Conditions

Finding Malware

Malware operates by entering the memory of your computer, as nothing can execute unless it’s loaded into memory and processed by the CPU.

• To run, malware must find a way into memory, where it can interact with various running processes like DLLs, threads, buffers, and memory management functions.

• Once in memory, the malware can either run as a standalone process or inject itself into an existing process, allowing it to execute without detection by the user or security software.

Memory Injection

Involves inserting malware into an existing process running in memory. Each process has a starting and ending memory address, and the malware is injected between these two addresses.

• This tactic allows the malware to avoid detection by anti-malware tools that are monitoring for malicious processes.

• Additionally, since the malware is injected into an existing process, it inherits the same rights and permissions as that process. This can lead to privilege escalation.

DLL injection

A technique where attackers use a malicious Dynamic-Link Library (DLL) to inject code into a target process.

• A DLL is a type of executable file containing code and data that multiple processes can use.

• For DLL injection to work, the attacker must first install the malicious DLL onto a storage drive that the system can access.

• The attacker then inserts a path or link to the malicious DLL into the target process.

• When the process reaches the point where it needs to reference the DLL, it pulls the malicious one from disk and loads it into memory, allowing the malware to run within the context of the target process.

• This method is popular and relatively easy to implement.

Buffer Overflow

Occurs when an attacker writes more data into a specific area of memory than it can hold, causing the excess data to overflow into adjacent areas.

• Developers can prevent this by performing bounds checking to ensure that only the expected amount of data is written into memory, such as 8 bytes instead of more.

• Attackers exploit this vulnerability by testing different parts of an application to see if they can manipulate its behavior.

• While a buffer overflow can sometimes cause a system or application to crash, the real goal is to find a repeatable overflow that grants the attacker a specific advantage, potentially compromising the system.

Buffer Overflow Example

• Two variables, A and B, are stored in memory.

• Variable A is initially empty and can hold 8 bytes, while variable B already contains a value of 1979 and is 2 bytes long.

• Variable B controls the user rights for the application, with values below 2000 granting guest rights and values above 24,000 granting administrative rights.

• By writing 9 bytes into variable A (which only holds 8 bytes), the extra byte overflows into variable B.

• The attacker chooses the word "excessive," which is 9 characters long. The first 8 characters are written into variable A, while the ninth character, "E" (hex value 65), overflows into the first byte of variable B, changing its value from 1979 to 25,856.

• Since this value is over 24,000, the attacker gains administrative rights for the application.

Race Condition

Occurs when two events happen almost simultaneously in an application, and the application doesn't account for the possibility of these events overlapping. This can lead to unexpected outcomes if the system isn't designed to handle such situations.

• A common example of a race condition is the Time-of-Check to Time-of-Use (TOCTOU) attack.

• In this scenario, an application checks the system for a value, retrieves it, and then performs an action based on that value.

• However, between the time the system is checked and when the value is used, another process might change that value.

• If the application doesn't anticipate this change, a race condition can occur, potentially allowing an attacker to exploit the situation.

Example of a Race Condition

Two users—User 1 and User 2—are interacting with two accounts, Account A and Account B, each initially holding $100. The application processes deposits immediately but does not update withdrawals in real-time.

• User 1 then transfers $50 from Account A to Account B, so Account A now has $100 and Account B has $150.

• User 2 also transfers $50 to Account B, resulting in Account A still showing $100, and Account B now showing $200.

• User 1 withdraws $50 from Account A. Now, Account A has $50 and Account B has $200.

• User 2 also attempts to withdraw $50 from Account A. However, because withdrawals are not updated immediately across all users, User 2 sees Account A as having $50 and Account B as $200.

The race condition occurs because the application hasn't updated the withdrawal from Account A for User 1 yet. As a result, User 2's withdrawal is processed without considering that User 1 already withdrew $50, causing an incorrect final balance of $50 in Account A and $200 in Account B when the actual balance should be $0 in Account A.

Real Life Examples Of Race Conditions

• January 2004 - Mars Rover “Spirit”:

• The rover’s system encountered a file system problem, which triggered a reboot. Unfortunately, this created a reboot loop, preventing the rover from continuing its operations.

• Pwn2Own Vancouver 2023 - Tesla Model 3: A TOCTOU (Time-of-Check to Time-of-Use)

• Attack was successfully executed against the Tesla Infotainment system using Bluetooth. By exploiting a race condition, the attacker elevated privileges to gain root access to the car's system.