Investigadors de l'equip Google Project Zero van donar a conèixer fa poc mitjançant una publicació de bloc un nou mètode d'explotació de vulnerabilitats (CVE-2020-29661) en la implementació del manejador ioctl TIOCSPGRP del subsistema tty del nucli de Linux, així com mecanismes de protecció detallats que podrien bloquejar aquestes vulnerabilitats.
S'esmenta a la publicació que el problema és causat per un error en la configuració de bloquejos, el que porta a una condició de carrera al codi de /tty/tty_jobctrl.c, que es va fer servir per crear condicions per accedir a la memòria després del seu llançament (use-after-free), explotat per l'usuari espai a través de la manipulació amb ioct- trucant a TIOCSPGRP.
Addicional a la informació publicada, també es va realitzar una demostració d'un exploit funcional per a l'escalada de privilegis a Debian 10 amb nucli 4.19.0-13-amd64 i el qual també no es descarta que pugui afectar diverses distribucions, entre les quals és clar les basades i derivades de Debian.
Moltes de les tècniques d'explotació individual i les opcions de mitigació que estic descrivint aquí no són noves. Tanmateix, crec que és valuós escriure'ls junts per mostrar com interactuen diverses mitigacions amb un exploit d'ús després de lliure força normal.
Els fragments de codi en aquesta publicació de bloc que són rellevants per a l'exploit es prenen de la versió anterior 4.19.160, ja que en això es basa el nucli de Debian objectiu; alguns altres fragments de codi són de la línia principal de Linux.
Al mateix temps, a l'article publicat, l'èmfasi no està tant en la tècnica de crear un exploit funcional, sinó en quines eines existencial al nucli per protegir-se contra aquestes vulnerabilitats.
La conclusió és decebedora, ja que s'esmenta que els mètodes com segmentar la memòria a la pila i controlar l'accés a la memòria després que s'allibera no s'apliquen a la pràctica, ja que condueixen a una disminució del rendiment ia la protecció basada en CFI (Control Flow Integrity), que bloqueja exploits a les últimes etapes d'un atac, requereix millores.
Un tipus especial de dispositiu terminal són els pseudoterminals, que s'utilitzen quan, per exemple, obre una aplicació de terminal en un entorn gràfic o es connecta a una màquina remota a través de SSH. Mentre altres dispositius terminals estan connectats a algun tipus de maquinari, tots dos extrems d'un pseudoterminal estan controlats per l'espai d'usuari, i els pseudoterminals poden ser creats lliurement per l'espai d'usuari (sense privilegis).
Cada vegada que /dev/ptmxse obre (abreviatura de «multiplexor pseudoterminal»), el descriptor de fitxer resultant representa el costat del dispositiu (al qual es fa referència a la documentació i les fonts del kernel com a « el pseudoterminal master») d'un nou pseudoterminal.
El dispositiu terminal corresponent (al qual normalment es connecta un shell) és creat automàticament pel kernel sota /dev/pts/ .
En observar allò que podria marcar la diferència a llarg termini, l'èmfasi està en l'ús d'analitzadors estàtics avançats o en l'ús de llenguatges segurs per a la memòria com els dialectes Rust i C amb anotacions esteses (com C comprovat) per construir dames de estat, panys, objectes i punters. Els mètodes de protecció també esmenten l'activació del mode panic_on_oops, fent que les estructures del kernel siguin de només lectura i restringint l'accés a les trucades al sistema mitjançant mecanismes com ara seccomp.
L'error que causava el problema es va solucionar al nucli de Linux el 3 de desembre de l'any passat. el problema es manifesta als nuclis anteriors a la versió 5.9.13, però la majoria de les distribucions han solucionat el problema a les actualitzacions del paquet del nucli que es van oferir l'any passat.
També s'esmenta una vulnerabilitat similar (CVE-2020-29660) que es va trobar simultàniament en la implementació de l'anomenada ioctl TIOCGSID, però també es va eliminar a tot arreu.
Finalment si estàs interessat en poder conèixer més a l'respecte, pots consultar els detalls en el següent enllaç.