{"id":104360,"date":"2022-06-12T09:36:50","date_gmt":"2022-06-12T07:36:50","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme"},"modified":"2022-06-12T09:36:50","modified_gmt":"2022-06-12T07:36:50","slug":"uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/uyazvimost-v-firejail-pozvolyayushhaya-poluchit-root-dostup-v-sisteme","title":{"rendered":"Vulnerabilit\u00e0 in firejail che consente l'accesso root al sistema","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nell'utility per l'esecuzione isolata delle applicazioni Firejail \u00e8 stata rilevata una vulnerabilit\u00e0 (CVE-2022-31214) che consente a un utente locale di ottenere diritti di root nel sistema principale. \u00c8 disponibile un exploit funzionante, testato nelle versioni attuali di openSUSE, Debian, Arch, Gentoo e Fedora con l'utility firejail installata. Il problema \u00e8 stato risolto nella versione firejail 0.9.70. Come soluzione alternativa, \u00e8 possibile impostare nelle configurazioni (\\\/etc\\\/firejail\\\/firejail.config) i parametri \u00abjoin no\u00bb e \u00abforce-nonewprivs yes\u00bb. <\/p>\n
Firejail utilizza per l'isolamento il meccanismo degli spazi dei nomi (namespaces), AppArmor e la filtrazione delle chiamate di sistema (seccomp-bpf) in Linux, ma per configurare l'esecuzione isolata richiede privilegi elevati, che ottiene tramite l'associazione all'utility con il flag suid root o eseguendo tramite sudo. La vulnerabilit\u00e0 \u00e8 causata da un errore nella logica di funzionamento dell'opzione \u00ab--join=\u00bb, destinata a collegarsi a un ambiente isolato gi\u00e0 in esecuzione (simile al comando login per l'ambiente sandbox) identificando l'ambiente tramite l'identificatore di processo in esecuzione. Fino a prima del ripristino dei privilegi, firejail determina i privilegi del processo specificato e li applica al nuovo processo che si connette all'ambiente tramite l'opzione \u00ab--join\u00bb. <\/p>\n
Prima di collegarsi, viene effettuato un controllo per verificare se il processo specificato sia in esecuzione nell'ambiente firejail. Questo controllo valuta l'esistenza del file \\\/run\\\/firejail\\\/mnt\\\/join. Per sfruttare la vulnerabilit\u00e0, l'attaccante pu\u00f2 simulare un ambiente firejail non isolato, utilizzando lo spazio dei punti di montaggio (mount namespace), per poi collegarsi ad esso tramite l'opzione \u00ab--join\u00bb. Se nelle impostazioni non \u00e8 attivata la modalit\u00e0 di divieto di acquisizione di privilegi aggiuntivi nei nuovi processi (prctl NO_NEW_PRIVS), firejail collegher\u00e0 l'utente a un ambiente fasullo e tenter\u00e0 di applicare le impostazioni dello spazio dei nomi degli identificatori utente (user namespace) del processo init (PID 1). <\/p>\n
Alla fine, il processo connesso tramite «firejail —join» si trover\u00e0 nello spazio dei nomi degli identificatori utente originale dell'utente, con privilegi invariati, ma in un diverso spazio di mount, completamente controllato dall'attaccante. Questo significa che l'attaccante pu\u00f2 eseguire programmi setuid-root nel proprio spazio di mount, permettendo, ad esempio, di modificare le impostazioni di \/etc\/sudoers o i parametri PAM nella propria gerarchia di file e ottenere la possibilit\u00e0 di eseguire comandi con i diritti root utilizzando gli strumenti sudo o su. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"