Pack2TheRoot minaccia Linux sfruttando un bug in PackageKit

Una nuova vulnerabilità, battezzata Pack2TheRoot, minaccia un'ampia fetta dell'ecosistema Linux desktop e server. La falla risiede in PackageKit - il demone D-Bus che astrae la gestione dei pacchetti su distribuzioni diverse - e permette a un utente locale senza privilegi di ottenere accesso root completo. Il punteggio CVSSv3 assegnato è 8.8, ovvero critico. E la parte peggiore: exploit pubblici sono attesi a breve.

La falla è stata catalogata come CVE-2026-41651.

Dodici anni di codice vulnerabile

A scoprire il problema è stato il Red Team di Deutsche Telekom, nell'ambito di una ricerca mirata sui vettori di escalation locale nei sistemi Linux moderni. La vulnerabilità interessa tutte le versioni di PackageKit dalla 1.0.2 alla 1.3.4 compresa.

PackageKit 1.0.2 è stato rilasciato oltre dodici anni fa, il che significa che la superficie d'attacco storica è enorme. Ogni sistema che abbia installato il demone packagekitd in quel lasso di tempo è potenzialmente esposto.

L'elenco delle distribuzioni confermate come vulnerabili nelle rispettive installazioni predefinite è lungo e trasversale: da Ubuntu Desktop 18.04 (ormai fuori supporto), 24.04.4 LTS e 26.04 LTS, a Ubuntu Server nelle versioni 22.04-24.04 LTS. Sono coinvolte Debian Desktop Trixie 13.4, RockyLinux Desktop 10.1, Fedora 43 sia Desktop che Server, e le istanze di Red Hat Enterprise Linux che utilizzano Cockpit. Persino SailfishOS risulta coinvolta, benché la comunità ne noti una criticità inferiore dato il contesto mono-utente tipico di uno smartphone.

I backend testati e confermati come vulnerabili sono apt e dnf.

Tre bug, una race condition

La classificazione CWE è CWE-367: race condition Time-of-Check Time-of-Use (TOCTOU). Il problema non è un singolo errore, ma l'interazione di tre difetti distinti nel file src/pk-transaction.c, che insieme permettono di aggirare l'autorizzazione di Polkit.

Il primo difetto si annida alla riga 4036: metodi come InstallFiles() scrivono i flag forniti dal chiamante direttamente nel campo transaction->cached_transaction_flags senza verificare se la transazione sia già autorizzata o in stato RUNNING. Una seconda invocazione sovrascrive i flag alla cieca, anche mentre la transazione è in esecuzione.

Alle righe 873-882, la funzione pk_transaction_set_state() scarta silenziosamente le transizioni di stato illegittime - per esempio da RUNNING a WAITING_FOR_AUTH - ma a quel punto la sovrascrittura dei flag è già avvenuta. La transazione prosegue con flag corrotti, e il flusso di esecuzione principale non viene interrotto.

Il terzo difetto, alle righe 2273-2277, chiude il cerchio: il callback idle dello scheduler legge cached_transaction_flags al momento del dispatch, non al momento dell'autorizzazione. Se i flag sono stati sovrascritti nell'intervallo tra autorizzazione ed esecuzione, il backend del gestore di pacchetti riceve i flag dell'attaccante.

Il risultato è elegante nella sua pericolosità. Un utente locale senza privilegi può installare pacchetti arbitrari come root - inclusa l'esecuzione di scriptlet RPM - senza alcuna autenticazione. L'unico prerequisito è disporre di un account locale su un sistema con PackageKit installato, e il gioco è fatto: compromissione completa del sistema.

La correzione e cosa fare adesso

La versione corretta è PackageKit 1.3.5. Il commit di riferimento (PackageKit/PackageKit@76cfb67) impedisce la re-invocazione di metodi su transazioni che non si trovano più nello stato iniziale, chiudendo la finestra temporale che consente la sovrascrittura dei flag. Un intervento chirurgico: si blocca il problema alla radice, senza ristrutturare l'intera gestione delle transazioni.

Chi amministra server Linux domestici, workstation o macchine desktop con una delle distribuzioni elencate dovrebbe verificare subito la versione di PackageKit installata. Il comando è banale: pkcon --version. Se il numero restituito è compreso tra 1.0.2 e 1.3.4, il sistema è vulnerabile. Aggiornare alla 1.3.5 - o rimuovere PackageKit dove non strettamente necessario - è l'unica mitigazione concreta.

Con exploit pubblici all'orizzonte e una base di installazioni che attraversa oltre un decennio di release, dodici anni sono tanti per lasciare una porta aperta verso root. 🔐

Fonti: github.com, forum.sailfishos.org, cvereports.com