Lors du fuzzing, le crash qui a attiré l'attention était lié à un use-after-free d'un objet task_struct alors qu'un mutex était détenu :```
==================================================================
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
==================================================================

Cette vulnérabilité a été découverte en fuzzant le pilote TEE sans qu'aucune session ne soit établie avec une TA existante sur le système. Cela pourrait être étendu avec les soi-disant pseudo-syscalls dans syzkaller afin de configurer et initier une session vers une TA.

## Analyse de la cause racine
La conclusion est un problème de conception dans le suivi de la durée de vie d'un objet `tee_shm:dmabuf`. Le pilote est conçu pour permettre à l'espace utilisateur de conserver la seule et unique référence après un appel à `tee_ioctl_shm_alloc()`.

On suppose que si l'objet est toujours présent dans l'IDR du pilote, alors la référence au dmabuf est toujours valide et son compteur de référence peut être incrémenté. Il s'avère que cela n'est que partiellement vrai. La mémoire du dmabuf est toujours possédée par le pilote dmabuf, mais elle peut être en cours de destruction et cela ne peut pas être arrêté en rendant le compteur de référence non nul à nouveau.

Le scénario qui déclenche le problème est une application multi-threadée où un thread ferme le descripteur de fichier du dmabuf en même temps qu'un autre thread appelle la commande IOCTL `TEE_IOC_OPEN_SESSION` ou `TEE_IOC_INVOKE` en référençant cette mémoire partagée.

Tracer la destruction du dmabuf lorsque l'espace utilisateur ferme le fd exécutera ce code dans le noyau :

1. `fput()`

2. `fput_many()`  >> Le compteur de référence du fichier atteint zéro. La fenêtre de concurrence s'ouvre.

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)` >> Désormais, l'objet shm ne peut plus être référencé depuis l'espace utilisateur. La fenêtre de concurrence se ferme.

     10. `mutex_unlock()`
  
Cela signifie que la table IDR et son verrou mutex ne peuvent pas garantir que le dmabuf et le `tee_shm` correspondant sont toujours vivants. Un processus en concurrence avec `fput()` en appelant `tee_shm_get_from_id()` peut obtenir une référence à un shm qui est sur le point de devenir mort.```
/**
 * 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'objet `tee_shm` pourrait être réalloué avant l'UAF car il appartient au cache kmalloc-64. Il faudrait le réallouer avec :

1. des objets factices `tee_shm`, `tee_shm:dmabuf`, `dma_buf:file`
2. définir `file->f_count = 1`
3. créer un objet `file:file_operations` dont le pointeur de fonction `fasync` est défini sur une adresse arbitraire

Cette fonction est ensuite invoquée dans `__fput()` après l'appel à `dma_buf_put()` lorsque `file->f_count` atteint zéro.

PAN (Privileged Access Never) atténue cette vulnérabilité car les objets factices doivent être référencés dans la mémoire espace utilisateur pour définir un pointeur de fonction arbitraire dans la structure `file:f_ops`. Par conséquent, `CONFIG_CPU_SW_DOMAIN_PAN` doit être désactivé pour que cela fonctionne, ce qui est le cas dans l'environnement fourni. Il reste quelques questions ouvertes quant à savoir si PAN peut être contourné dans cette vulnérabilité, par exemple en utilisant ret2dir.

De plus, pour réussir une réallocation de l'objet shm libéré, l'appel IOCTL `TEE_IOC_OPEN_SESSION` ou `TEE_IOC_INVOKE` doit être anticipé par un thread effectuant la fermeture du descripteur de fichier et un thread de « heap spraying » qui remplit le cache kmalloc-64. Pour que cela fonctionne, le noyau doit être configuré avec `CONFIG_PREEMPT`. Dans cette Preuve de Concept, le « heap spray » de l'article de blog de Nicolas Fabretti [7] a été utilisé, basé sur `sendmsg()` bloquant.

Pour résumer, le problème concernant l'exploitation est que la libération et l'UAF doivent toutes deux se produire dans le même appel système. De plus, la libération est difficile à déclencher car elle nécessite une compétition au sein de l'appel système. Après la libération, l'intervalle de temps entre celle-ci et l'UAF effective est une petite fenêtre temporelle où un « heap spray » doit être effectué pour réallouer l'objet libéré. La figure suivante montre les threads impliqués dans le code d'exploitation et leur rôle.

<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 impliqués dans le code d'exploitation</em>
</p>

Trois types de threads sont exécutés en continu. Afin de préempter le thread appelant système, celui-ci s'exécute avec la priorité la plus basse possible, `SCHED_IDLE`, tandis que les autres ont la priorité définie sur `SCHED_OTHER`. Comme nous utilisons `sendmsg()` bloquant, chaque tentative de « spray » doit s'exécuter dans son propre thread et doit s'exécuter sur le même cœur de CPU qui déclenche l'UAF, puisque chaque cœur conserve ses propres caches kmalloc. Il existe également un certain nombre de threads de libération qui ferment le descripteur de fichier provenant de l'allocation de mémoire partagée à l'étape 1b). Le code source complet pour ce déclenchement d'UAF et cette réécriture de pointeur de fonction se trouve à [10].

## Configuration du nouvel environnement
Pour reproduire l'environnement avec un noyau vulnérable et OPTEE, il peut être cloné depuis le dépôt suivant et construit en utilisant :```
$ 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

Cela s'arrêtera à cause de Privileged execute-never (PXN) bloquant l'exécution à `PC=0x22000000`. À partir de là, les stratégies d'exploitation peuvent varier selon la version du noyau, mais il pourrait être possible d'exécuter un kernel ROP et de faire du stack pivoting, ou de rendre la zone vDSO accessible en écriture et d'y placer la charge utile. Il pourrait également être intéressant pour de futurs travaux d'étudier si PAN peut être contourné en utilisant ret2dir et du physmap spraying. PAN peut être activé dans le noyau en définissant `CONFIG_CPU_SW_DOMAIN_PAN=y` dans `linux/.config`. Sur du matériel réel, il est activé par défaut sur ARMv8.1 et AArch64, pour ARMv7 et AArch32, il est possible d'avoir une émulation logicielle de PAN en utilisant ce paramètre [8].

**Note** : Cet exploit n'est pas très bien optimisé et peut occasionnellement bloquer le pilote s'il parvient à libérer l'objet mémoire partagée trop tôt, auquel cas PC sera à `tee_shm_get_from_id()`. Si cela se produit, exécutez `system_reset` dans la console QEMU pour redémarrer l'environnement.

## Remerciements
Merci à Lars Persson d'Axis Communications pour son aide dans l'analyse de la cause racine et à Jens Wiklander de Linaro et mainteneur du sous-système TEE pour une communication fluide et une résolution rapide de ce problème [9].

## Références 

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

[2] Sous-système TEE - 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: Une douce introduction à l'exécution de confiance et OP-TEE - https://connect.linaro.org/resources/bkk16/bkk16-110/

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

[7] Blog de sécurité de Lexfo, par Nicolas Fabretti : CVE-2017-11176 : Une exploitation pas à pas du noyau Linux - https://blog.lexfo.fr/cve-2017-11176-linux-kernel-exploitation-part3.html

[8] Sous-système de sécurité du noyau Linux : Méthodes d'exploitation/Utilisation des données de l'espace utilisateur - 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] Exploit de preuve de concept - https://github.com/pjlantz/optee_examples/tree/master/exploit/host