Background

Let’s take a look at the following piece of code:

if (is_infected_file(path)) {
  remove_file(path);
}

This is a oversimplified routine from a typical antivirus scanner — it takes a file path, checks data of that file using malware signatures, and removes the file if it’s “infected”.

However, if the remove_file() routine follows symlinks (i.e., it deletes a symlink target, not a symlink itself), security problems arise…

A malicious program can create a file, fill it with bytes that are detected by a specific antivirus engine (e.g., write the EICAR string), trigger the antivirus scan somehow (e.g., by trying to read that file, thus triggering on-access scans), and then quickly replace that file with a symlink to another file.

This leads to a well-known race condition: the is_infected_file() routine deals with one file, but, occasionally, the remove_file() routine deals with another file! The path is the same, but in these two routines it points to different files: one is a regular file that is detected as “infected”, another one is a symlink pointing somewhere.

If the attacker is lucky enough, the remove_file() routine deletes the symlink target (which is attacker-chosen).

This leads to many possible issues, including denial-of-service (when an important system file is deleted), privilege escalation (when a configuration file with security-related settings is deleted, forcing some software to use “less secure” defaults), or even information disclosure (when software creating a backup is forced to copy sensitive files to a world-readable location).

In general, symlink attacks allow low-privileged programs to do some unintended actions against files they can’t access directly.

More examples can be found in this Wikipedia article and in this research paper.

There is one limitation: symlink attacks require code execution. In particular, attackers must create a file, trigger a vulnerable application, and then quickly replace that file with a symlink.

Challenge

What if no code execution is needed to mount such an attack?

The GRUB boot manager is more an operating system than a boot loader. For example, it has more than 20 file system types supported!

This is a really wide attack surface… And, currently, GRUB is the default choice in the Secure Boot implementation using Microsoft-signed shims (but things are moving forward).

Some time ago, I discovered two vulnerabilities (or three vulnerabilities, if we count a security issue which is almost unexploitable) in the NTFS driver of the GRUB boot manager. And here are some technical details…