It is important you choose passwords that are difficult to guess or crack. WRONG! Just press backspace 28 times!
Security researchers from the University of Valencia have found a bizarre exploit in several distributions of Linux That can bypass any kind of authentication during boot-up just by pressing backspace key 28 times.
Using this shell, you could gain access to all the data on your computer.
The Exploit (PoC)
Exploiting the integer underflow can be used to cause an Off-by-two or an Out of bounds overwrite memory errors. The former error, overwrites up to two bytes right under the username buffer (local variable called login at function grub_auth_check_authentication()), but this area does not contain any usable information to build an attack; actually, it is padding.
The latter error, the Out of bounds overwrite, is more interesting because it allows to overwrite with zeros the zone below to the username buffer. This is because the grub_memset() function tries to set to zero all unused bytes of the username buffer. To do that, the code calculates the address of the first unused byte and how many bytes have to be zeroed in the buffer. The results of these calculations are passed as arguments to the grub_memset() function:
grub_memset (buf + cur_len, 0, buf_size - cur_len);
For example, typing “root” as usermane, cur_len is 5, and the grub_memset() function will clear (set to zero) bytes form 5to 1024-5 (the username and password buffers are 1024 bytes) of the username buffer. This way of programming is quite robust. For example, if the typed username is stored in a clean 1024-byte array, then we can compare the whole 1024-bytes with the valid username, rather than comparing both strings. This protects against some short of side-channels attacks, like timing attacks.
To abuse the out of bound overwrite, the attacker can press the backspace key to underflow the cur_len variable, producing a very high value. This value is later used to calculate the starting address to clear.
memset destination address = buf + cur_len
At this point, a second overflow occurs because the addition of this big value with the base address where the username buffer resides can not be hold in a 32-bit variable. Hence, we need to manage the first underflow and this second overflow to calculate the destination address where the grub_memset() function will start to set to zeros the buffer: cur_len--; // Integer Underflow
grub_memset (buf + cur_len, 0, buf_size - cur_len); // Integer OverflowThe following example helps to understand how we can exploit this. Assuming that the username buffer resides in the address 0x7f674 and the attacker press the backspace key only once (producing an underflow to 0xFFFFFFFF) the resulting memset will be:
grub_memset (0x7f673, 0, 1025);
The first argument is: (buf+cur_len) = (0x7f674+0xFFFFFFFF) = (0x7f674-1) = 0x7f673, the second argument: is the constant value used to overwrite the area, in this case 0, and the third argument is the number of bytes to overwrite: (buf_size-cur_len) = (1024-(-1)) = 1025. Therefore, the whole username buffer (1024) plus the very first byte under the buffer will be set to zero.
Therefore, the number backspace keystrokes (without introducing any username), is the number of bytes below the username that are zeroed.
Now, we are able to overwrite an arbitrary number of bytes below the username, we need to find out an interesting memory address that we can overwrite with zeros. A quick look to the current stack frame reveals that we were able to overwrite the return address of the grub_memset() function. The following picture sketches the stack memory layout:
![]() |
Grub2: Redirecting the control flow.
|
As shown in the above picture, the return address of the grub_memset() function is at a distance of 16-bytes from the username buffer. In other words, if we press the backspace key 17 times, we will overwrite the highest byte of the return address. So, instead of returning to the caller function at 0x07eb53e8 we will jump to 0x00eb53e8. When thegrub_memset() ends, control flow is redirected to the the 0x00eb53e8 address causing a reboot. The same occurs if we press the backspace key 18, 19 or 20 times, in all cases the system reboots.
At this point, we are able to redirect the control flow.
We will skip the detailed analysis of the code at: 0x00eb53e8, 0x000053e8 and 0x000000e8, because they jump to code that reboots the computer and there is no way to control the execution flow.
Although it seems quite difficult to build a successful attack just jumping to 0x0, we will show how to do it.
Is there life after jumping to 0x0 ?
At address 0x0 resides the IVT (Interrupt Vector Table) of the processor. It contains a variety of pointers in the form of segment:offset.
![]() |
The lowest part of the IVT interpreted as code.
|
At this early stage of the boot sequence, the processor and the execution framework is not fully functional. Next are the main differences with respect to the execution environment of a regular process:
- The processor is in “protected mode”. Grub2 enables this mode at the very beginning.
- Virtual memory is not enabled.
- No memory protection. The memory is readable/writable/executable. That is, no NX/DEP.
- The processor executes the 32-bit instruction set, even in 64-bit architectures.
- Self modifying code is automatically handled by the processor: “If the write affects a prefetched instruction, the prefetch queue is invalidated.“
- No Stack Smashing Protector (SSP).
- No Address Space Layout Randomization (ASLR).
Therefore, jumping to 0x0 does not cause a trap by itself, but we need to control the execution flow to reach the target function grub_rescue_run() which contains the main loop of the Grub2 Rescue Shell.
What do we control when jumping to 0x0
| The main “while” loop of the grub_username_get() ends when the user hits either the [Enter] or the [Esc] key. The register %ebx contains the value of the last typed key (0xd or 0x8, Enter or Esc ascii codes respectively). The register %esi holds the value of the cur_len variable.The instruction pointer points to the 0x0 address. The %esi register contains the value -28 (the exploit works by pressing 28 times the backspace), and then hitting [Enter] (%ebx == 0xb). |
eax 0x7f658
ecx 0x0 (0)
edx 0x0 (0)
ebx 0xd (13)
esp 0x7f664
ebp 0x0 (0)
esi 0xffff ffe4 (-28)
edi 0x0 (0)
eip 0x0 (0)
esp 0x7f664
eflags 0x200046[ PF ZF ID ]
Relevant CPU registers. |
Reverse engineering of the IVT
If the state of the processor is the one summarized in the previous table, the code at IVT implements something like a memcpy(), which copies from the address pointed by %esi to 0x0 (to itself). Therefore, IVT is a self modifying code, and we can select the block of code that we want to copy from.
The following sequence shows the sequence of code actually executed the register %esi has the value -28 (0xffffffe4):
![]() |
First iteration.
|
![]() |
Second iteration.
|
In the third iteration, the resulting code contains a retw instruction at 0x0007. The value pointer by %esp is 0xe00c. And so, when the retw instruction is executed, the execution flow jumps into 0xe00c. This address belongs to the functiongrub_rescue_run():
<grub_rescue_run>:
0xdfef: push %ebp
0xdff0: mov %esp,%ebp
0xdff2: sub $0x24,%esp
0xdff5: push $0xe90a
0xdffa: call 0xd53b #
0xdfff: add $0x10,%esp
0xe002: call 0xbfd2 #
0xe007: xor %edx,%edx
0xe009: lea -0xc(%ebp),%eax
->0xe00c: movl $0x0,0x16ce0-->
0xe016: call 0xdf28
... ... ...
|
void __attribute__ ((noreturn)) grub_rescue_run (void){
. . .
while (1)
{
char *line;
/* Print an error, if any. */
grub_print_error ();
----->grub_errno = GRUB_ERR_NONE;
grub_rescue_read_line (&line, 0, NULL);
if (! line || line[0] == '\0')
continue;
grub_rescue_parse_line (line, grub_rescue_read_line,
NULL);
grub_free (line);
}
}
|
| Assembly code. |
Corresponding C function. |
|
At this point, GRUB2 is in the grub rescue function, which is a powerful shell.
![]() |
![]() |
| Right after 28 [Backspace] and [Enter]. |
We’ve got a fully operative rescue shell. |
Fortunately, the content of the memory has suffered minor modifications, and it is possible to use all the functionality of GRUB. Only, the first interrupt vector of the IVT has been modified, and since the processor is now in protected mode, the IVT is no longer used.
One step ahead
Although we reached the GRUB2 rescue function, we are not actually authenticated. If we return to the “normal” mode, that is the grub menu and with full editing capabilities, GRUB will ask for a valid user and password. So, we can directly start to type GRUB2 commands, or even including new modules to add new GRUB functionalities, to deploy the malware into the system or launch a much more comfortable environment by running a complete bash shell from a Linux. To run bash in Linux, we can use the GRUB2 commands like linux, initrd or insmod.
Although to use GRUB2 commands to run a Linux kernel to deploy the malware is perfectly possible, we found that, a simpler solution is to patch the code of GRUB2 in RAM to be always authenticated and then return to the “normal” mode. The idea to do that, is to modify the condition which checkes whether the user has been authenticated or not. This function is is_authenticated() in the file grub-core/normal/auth.c.
![]() |
| The goal is to overwrite the condition with nop instructions. |
This modification is done using the GRUB2 rescue command write_word. And then, everything is ready to return back to GRUB2’s normal mode. In other words, we can enter in the “edit mode” and GRUB2 will not ask for users or passwords.
![]() |
![]() |
grub rescue> write_word 0x7eb514e 0x90909090
grub rescue> normal
|
We’ve got a fully operative GRUB2. |
How an APT could use this 0-Day
Physical access is an “advanced” feature attributed to APTs (or insiders). One of the main goals of an APT is the theft of sensitive information or Cyberspying. The following is just a very simple example of how an APT could infect a system and obtain persistence to posteriorly steal data of a user. The following summarizes the system configuration:
- BIOS/UEFI is protected with password.
- GRUB2 edit mode is protected with password.
- External boots disabled: CDROM, DVD, USB, Netboot, PXE …
- The user data (HOME) is ciphered.
![]() |
Boot system Overview.
|
As pointed before, our goal is to steal data of an user. Since the data is ciphered, the strategy we will use is to infect the system and wait until the user decrypts the data (by login into the system) and then access to the information in plain.
Preparing the environment to deploy the malware
By patching the GRUB2 as shown before, we can easily edit the linux entry to load a Linux kernel and get a root shell. This is an old but still usable trick, just by adding init=/bin/bash to the linux entry, we will get a root Linux shell, which is a much more comfortable environment for deploying our malware.
![]() |
![]() |
| Adding /bin/bash to the linux GRUB2 command. |
Bash root shell in Linux. |
Note that since /bin/bash is the first process to run, the syslog daemon is not running, and so, logs are not recorded. That is, this access will not be detected using normal Linux monitoring.
Deploying the malware and obtaining persistence
In order to show how far you could go by exploiting this 0-Day Grub2 vulnerability, we have developed a simple PoC. This PoC is a modified Firefox library which creates a new process and run a reverse shell to a controlled server at port 53. Obviously, this is a simple example, and a real malware will exfiltrate the information much more stealthily.
The modified library was uploaded to virustotal reporting 0 infections/virus out of 55 tools. Firefox is a web browser that uses Internet, and makes requests to HTTP and DNS ports, so, it not appears to be suspicious that our malware talk with these ports.
To infect the system we simply put our modified libplc4.so library into a USB and then replace the original one. We have to mount with write permissions the system and mount the USB as shown in the following picture:
![]() |
Infecting the system.
|
When any user executes the Firefox, a reverse shell will be invoked. At this time all data of the user is deciphered, allowing us to steal any kind of information of the user. The following picture, shows how the user Bob (the target) is using the Firefox and how the user Alice (the attacker) has full access to Bob’s data.
![]() |
![]() |
| The victim browsing the web. |
The attacker with a reverse shell. |
|
To finish the persistence part, it worth to mention that by a simple Kernel modification that resides in the /bootpartition, which by default is not ciphered, we can elevate privileges to deploy a more persistent malware. The imagination is the limit.
