RAP è molto simile a un canary stack, eccetto progettato per prevenire contro ROP.
EDIT : dopo aver parlato con spender da grsecurity, si scopre che quello che sto descrivendo qui è un sottoinsieme della funzionalità RAP, in particolare la protezione del puntatore di ritorno. RAP è in realtà chiamato "Riutilizza protezione attacchi", progettato per proteggere da tutte le forme di chiamate indirette. Il documento che hai collegato descrive alcune delle funzionalità di RAP, di cui fanno parte sia la protezione del puntatore di ritorno che le funzioni di ICFG.
Possiamo vedere il seguente assembly dal foglio:
push %rbx
mov 8(%rsp),%rbx
xor %r12,%rbx
...
xor %r12,%rbx
cmp %rbx,8(%rsp)
jnz .error
pop %rbx
retn
.error:
ud2
Il primo blocco qui imposta il cookie RAP:
; store the old value of rbx
push %rbx
; read the top value on the stack (the return pointer) and put it in rbx
mov 8(%rsp),%rbx
; xor rbx with a random value stored in r12
; rbx now contains the RAP canary
xor %r12,%rbx
Quindi, alla fine della funzione, prima del ret:
; xor the RAP canary in rbx with the random value in r12
; this "decrypts" the stack pointer from the RAP canary
xor %r12,%rbx
; compare the top value on the stack (the return pointer)
; with the value decrypted from the RAP canary
cmp %rbx,8(%rsp)
; if the comparison fails, jump to error
jnz .error
; restore the original value of rbx
pop %rbx
; return
retn
.error:
; an error occured, quit the process
ud2
L'idea alla base di ROP è che troverai le istruzioni che desideri (gadget) seguite da un'istruzione di ritorno. Questa funzione di protezione riscrive le funzioni in modo che l'istruzione finale prima di ogni ritorno sia sempre un pop %rbx e le istruzioni precedenti vengono utilizzate per convalidare il canarino RAP. Ciò rende molto difficile trovare i gadget ROP al di fuori delle istruzioni non allineate (ad esempio, i gadget che esistono solo a causa dell'interpretazione binaria delle istruzioni al di fuori dell'allineamento normale).
La protezione può essere applicata a usermode e kernel. Il valore del cookie (il valore in% r12) viene rigenerato per attività, per syscall e per iterazione in alcuni loop infiniti (ad esempio gestori di eventi e cicli di invio). Il motivo dell'ultimo è che i loop infiniti usano spesso ret per uscire dal ciclo. (questo non è del tutto corretto).
EDIT: Dopo aver discusso di questo con Spender, suggerirò di aspettare che la spiegazione venga fuori. C'è un sacco di sottigliezza su come funziona la funzione e non sono sicuro di poterlo coprire accuratamente dal documento e dalla mia breve discussione su IRC. Una volta uscito aggiornerò questa risposta per darti un'idea migliore di ciò che fa.