Durante il fuzzing, il crash che ha attirato l'attenzione era legato a un use-after-free di un oggetto task_struct mentre un mutex era detenuto:```
==================================================================
BUG: KASAN: use-after-free in __mutex_lock.constprop.0+0x118c/0x11c4
Read of size 4 at addr 863b0714 by task optee_example_r/244
 
CPU: 0 PID: 244 Comm: optee_example_r Tainted: G      D           5.14.0 #151
Hardware name: Generic DT based system
[<8012b204>] (unwind_backtrace) from [<8011f460>] (show_stack+0x20/0x24)
[<8011f460>] (show_stack) from [<81cf0108>] (dump_stack_lvl+0x5c/0x68)
[<81cf0108>] (dump_stack_lvl) from [<80650f04>] (print_address_description.constprop.0+0x38/0x304)
[<80650f04>] (print_address_description.constprop.0) from [<80651548>] (kasan_report+0x1c0/0x1dc)
[<80651548>] (kasan_report) from [<81d0a9b4>] (__mutex_lock.constprop.0+0x118c/0x11c4)
[<81d0a9b4>] (__mutex_lock.constprop.0) from [<81d0ada4>] (mutex_lock+0x128/0x13c)
[<81d0ada4>] (mutex_lock) from [<817424b0>] (tee_shm_release+0x4b0/0x6cc)
[<817424b0>] (tee_shm_release) from [<81303674>] (dma_buf_release+0x1b8/0x2f0)
[<81303674>] (dma_buf_release) from [<806d5ac0>] (__dentry_kill+0x4c4/0x678)
[<806d5ac0>] (__dentry_kill) from [<806d8a68>] (dput+0x630/0xba4)
[<806d8a68>] (dput) from [<8067d890>] (__fput+0x3b4/0x900)
[<8067d890>] (__fput) from [<801dd1d8>] (task_work_run+0x15c/0x230)
[<801dd1d8>] (task_work_run) from [<80172b70>] (do_exit+0x103c/0x3770)
[<80172b70>] (do_exit) from [<80179aec>] (do_group_exit+0x134/0x3ac)
[<80179aec>] (do_group_exit) from [<801a7658>] (get_signal+0x7d8/0x2f28)
[<801a7658>] (get_signal) from [<8011dea4>] (do_work_pending+0x984/0x154c)
[<8011dea4>] (do_work_pending) from [<801000d0>] (slow_work_pending+0xc/0x20)
Exception stack(0x85743fb0 to 0x85743ff8)
3fa0:                                     00023108 00000080 00000000 00000000
3fc0: 66bca2d0 66bca2d0 66bca2d0 000000f0 66bca2d0 66bca340 00000000 6ec00b0c
3fe0: 66bc9cc8 66bc9cb8 00011655 66c80c20 000e0130 00023108
 
Allocated by task 242:
 set_alloc_info+0x48/0x50
 __kasan_slab_alloc+0x48/0x58
 kmem_cache_alloc+0x14c/0x314
 copy_process+0x2014/0x7b18
 kernel_clone+0x244/0xfc8
 sys_clone+0xc8/0xec
 ret_fast_syscall+0x0/0x58
 0x6ec00a10
 
Freed by task 67:
 kasan_set_track+0x28/0x30
 kasan_set_free_info+0x20/0x34
 __kasan_slab_free+0xdc/0x108
 kmem_cache_free+0x80/0x394
 __put_task_struct+0x2b4/0x35c
 delayed_put_task_struct+0x104/0x384
 rcu_core+0x91c/0x2a68
 __do_softirq+0x2fc/0xfb8
 
Last potentially related work creation:
 kasan_record_aux_stack+0xb8/0xc0
 call_rcu+0x9c/0xfd0
 put_task_struct_rcu_user+0x9c/0xbc
 finish_task_switch+0x534/0xa10
 __schedule+0x934/0x1adc
 schedule_idle+0x9c/0x120
 do_idle+0x2ec/0x434
 cpu_startup_entry+0x18/0x1c
 start_kernel+0x3ec/0x430
 
The buggy address belongs to the object at 863b0700
 which belongs to the cache task_struct of size 1664
The buggy address is located 20 bytes inside of
 1664-byte region [863b0700, 863b0d80)
The buggy address belongs to the page:
page:f09c9565 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x463b0
head:f09c9565 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x10200(slab|head|zone=0)
raw: 00010200 00000000 00000122 82802e00 00000000 80120012 ffffffff 00000001
page dumped because: kasan: bad access detected
 
Memory state around the buggy address:
 863b0600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 863b0680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>863b0700: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                 ^
 863b0780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 863b0800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

Questa vulnerabilità è stata scoperta eseguendo fuzzing sul driver TEE senza che fosse stata stabilita alcuna sessione con una TA esistente in esecuzione sul sistema. Ciò potrebbe essere ulteriormente esteso con le cosiddette pseudo syscall in syzkaller per impostare e avviare una sessione verso una qualche TA.

## Analisi della causa principale

La conclusione è un problema di progettazione nel tracciamento del ciclo di vita di un oggetto `tee_shm:dmabuf`. Il driver è progettato per lasciare che lo spazio utente mantenga l'unico e solo contatore di riferimenti dopo una chiamata a `tee_ioctl_shm_alloc()`.

Si presume che se l'oggetto è ancora presente nell'oggetto IDR del driver, allora il riferimento al dmabuf sia ancora valido e il suo contatore di riferimenti possa essere incrementato. In realtà questo è solo parzialmente vero. La memoria del dmabuf è ancora di proprietà del driver dmabuf, ma potrebbe essere in procinto di essere distrutta e questo non può essere fermato riportando il contatore di riferimenti a un valore diverso da zero.

Lo scenario che innesca il problema è un'applicazione multi-thread in cui un thread chiude il descrittore di file del dmabuf nello stesso momento in cui un altro thread effettua una chiamata al comando IOCTL `TEE_IOC_OPEN_SESSION` o `TEE_IOC_INVOKE` facendo riferimento a quella memoria condivisa.

Tracciando la distruzione del dmabuf quando lo spazio utente chiude il fd, nel kernel verrà eseguito questo codice:

1. `fput()`

2. `fput_many()`  >> Il contatore dei riferimenti del file raggiunge lo zero. Si apre la finestra di race condition.

3. `[task_work gets scheduled]`

4. `__fput`

5. `dput`

6. `dma_buf_release`

7. `tee_shm_release`

     8. `mutex_lock(teedev->mutex)`

     9. `idr_remove(teedev->idr, shm->id)` >> Ora l'oggetto shm non può più essere referenziato dallo spazio utente. La finestra di race condition si chiude.

     10. `mutex_unlock()`
  
Questo significa che la tabella IDR  e il suo mutex non possono garantire che il dmabuf e il corrispondente `tee_shm` siano ancora vivi. Un processo che compete con `fput()` chiamando `tee_shm_get_from_id()` può ottenere un riferimento a uno shm che sta per essere distrutto.```
/**
 * tee_shm_get_from_id() - Find shared memory object and increase reference
 * count
 * @ctx:    Context owning the shared memory
 * @id:     Id of shared memory object
 * @returns a pointer to 'struct tee_shm' on success or an ERR_PTR on failure
 */
struct tee_shm *tee_shm_get_from_id(struct tee_context *ctx, int id)
{
    struct tee_device *teedev;
    struct tee_shm *shm;
 
    if (!ctx)
        return ERR_PTR(-EINVAL);
 
    teedev = ctx->teedev;
    mutex_lock(&teedev->mutex);
    shm = idr_find(&teedev->idr, id);
    if (!shm || shm->ctx != ctx)
        shm = ERR_PTR(-EINVAL);
    else if (shm->flags & TEE_SHM_DMA_BUF)
        get_dma_buf(shm->dmabuf);
    mutex_unlock(&teedev->mutex);
    return shm;
}

L'oggetto `tee_shm` potrebbe essere riallocato prima della UAF poiché appartiene alla cache kmalloc-64. Dovrebbe essere riallocato con:

1. oggetti fittizi `tee_shm`, `tee_shm:dmabuf`, `dma_buf:file`
2. impostare `file->f_count = 1`
3. creare un oggetto `file:file_operations` che abbia il puntatore a funzione `fasync` impostato su un indirizzo arbitrario

Questa funzione viene poi invocata in `__fput()` dopo la chiamata a `dma_buf_put()` quando `file->f_count` raggiunge lo zero.

PAN (Privileged Access Never) mitiga questo aspetto poiché gli oggetti fittizi devono essere referenziati nella memoria dello spazio utente per poter impostare un puntatore a funzione arbitrario nella struttura `file:f_ops`. Pertanto, `CONFIG_CPU_SW_DOMAIN_PAN` deve essere disabilitato affinché funzioni, e lo è nell'ambiente fornito. Rimangono alcune domande aperte sulla possibilità di aggirare PAN in questa vulnerabilità, ad esempio usando ret2dir.

Inoltre, per effettuare con successo la riallocazione dell'oggetto shm deallocato, la chiamata IOCTL `TEE_IOC_OPEN_SESSION` o `TEE_IOC_INVOKE` deve essere soggetta a preemption da parte di un thread che esegue la chiusura del file descriptor e di un thread di heap spraying che riempie la cache kmalloc-64. Affinché ciò funzioni, il kernel deve essere configurato con `CONFIG_PREEMPT`. In questo PoC è stato utilizzato l'heap spray dal post del blog di Nicolas Fabretti [7], basato su `sendmsg()` bloccante.

Per riassumere, il problema per quanto riguarda lo sfruttamento è che sia la free che la UAF devono avvenire all'interno della stessa chiamata di sistema. Inoltre, la free è difficile da innescare perché richiede una race condition all'interno della syscall. Dopo la free, il tempo tra questa e l'effettiva UAF è una piccola finestra temporale in cui deve essere eseguito un heap spray per riallocare l'oggetto deallocato. La figura seguente mostra i thread coinvolti nel codice dell'exploit e il loro ruolo.

<p align="center">
  <img src="https://raw.githubusercontent.com/pjlantz/pjlantz.github.io/master/docs/assets/Threads.png?raw=true" alt="Threads involved" width="50%" height="50%"/>
       <br /><em>Figure 3: Threads involved in the exploit code</em>
</p>

  
Tre tipi di thread sono in esecuzione continua. Per preemptare il thread che effettua la chiamata di sistema, esso gira con la priorità più bassa possibile, `SCHED_IDLE`, mentre gli altri hanno la priorità impostata su `SCHED_OTHER`. Poiché stiamo usando `sendmsg()` bloccante, ogni tentativo di spray deve girare nel proprio thread e deve girare sullo stesso core CPU che innesca la UAF, dato che ogni core mantiene le proprie cache kmalloc. Ci sono anche diversi thread di freeing che chiudono il file descriptor dell'allocazione di memoria condivisa del passaggio 1b). Il codice sorgente completo per questo trigger di UAF e la sovrascrittura del puntatore a funzione si trova in [10].

## Setting up the new environment
Per riprodurre l'ambiente con un kernel vulnerabile e OPTEE, può essere clonato dal seguente repository e compilato usando:```
$ mkdir optee-qemu && cd optee-qemu
$ repo init -u https://github.com/pjlantz/optee-qemu.git
$ repo sync
$ cd build
$ make toolchains -j2
$ make run

Questo si fermerà a causa del blocco dell'esecuzione Privileged execute-never (PXN) a `PC=0x22000000`. Da qui in poi, le strategie di sfruttamento possono variare a seconda della versione del kernel, ma potrebbe essere possibile eseguire una ROP nel kernel e fare stack pivoting, oppure rendere scrivibile l'area vDSO e collocare lì il payload. Potrebbe anche essere interessante, per lavori futuri, verificare se la PAN può essere aggirata usando ret2dir e un po' di physmap spraying. La PAN può essere abilitata nel kernel impostando `CONFIG_CPU_SW_DOMAIN_PAN=y` in `linux/.config`. Su hardware reale, è abilitata per impostazione predefinita su ARMv8.1 e AArch64; per ARMv7 e AArch32 è possibile avere una PAN emulata via software usando questa impostazione [8]. 

**Nota**: questo exploit non è molto ottimizzato e potrebbe occasionalmente bloccare il driver se riesce a liberare l'oggetto di memoria condivisa troppo presto; in questo caso PC sarà in `tee_shm_get_from_id()`. Se ciò accade, esegui un `system_reset` nella console QEMU per riavviare l'ambiente.

## Ringraziamenti
Grazie a Lars Persson di Axis Communications per l'aiuto con l'analisi della causa radice e a Jens Wiklander di Linaro, nonché maintainer del sottosistema TEE, per una comunicazione fluida e la rapida risoluzione di questo problema [9].

## Riferimenti 

[1] CVE-2021-44733 - https://nvd.nist.gov/vuln/detail/CVE-2021-44733

[2] TEE subsystem - https://www.kernel.org/doc/html/latest/staging/tee.html

[3] Globalplatform TEE API - https://globalplatform.org/specs-library/?filter-committee=tee

[4] OP-TEE OS - https://github.com/OP-TEE/optee_os

[5] BKK16-110: A Gentle Introduction to Trusted Execution and OP-TEE - https://connect.linaro.org/resources/bkk16/bkk16-110/

[6] Syzkaller - https://github.com/google/syzkaller 

[7] Lexfo's security blog, by Nicolas Fabretti: CVE-2017-11176: A step-by-step Linux Kernel exploitation - https://blog.lexfo.fr/cve-2017-11176-linux-kernel-exploitation-part3.html

[8] Linux Kernel Security Subsystem: Exploit Methods/Userspace data usage - http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage

[9] [PATCH v2] tee: handle lookup of shm with reference count 0 - https://lore.kernel.org/lkml/[email protected]/T/ 

[10] Proof of concept exploit - https://github.com/pjlantz/optee_examples/tree/master/exploit/host