{"id":169899,"date":"2026-04-24T18:24:34","date_gmt":"2026-04-24T16:24:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-rust-coreutils-vyyavleno-113-uyazvimostej-v-ubuntu-26-04-vozvrashheny-cp-mv-i-rm-iz-gnu-coreutils"},"modified":"2026-04-24T18:24:34","modified_gmt":"2026-04-24T16:24:34","slug":"v-rust-coreutils-vyyavleno-113-uyazvimostej-v-ubuntu-26-04-vozvrashheny-cp-mv-i-rm-iz-gnu-coreutils","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/v-rust-coreutils-vyyavleno-113-uyazvimostej-v-ubuntu-26-04-vozvrashheny-cp-mv-i-rm-iz-gnu-coreutils","title":{"rendered":"In Rust Coreutils sono state identificate 113 vulnerabilit\u00e0. In Ubuntu 26.04 sono tornati disponibili cp, mv e rm da GNU Coreutils","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
La compagnia Canonical ha pubblicato i risultati preliminari di un audit di sicurezza indipendente degli uutils coreutils (Rust Coreutils), scritto in Rust e parzialmente utilizzato in Ubuntu invece del pacchetto GNU Coreutils. L'audit \u00e8 stato eseguito da Zellic, un'azienda con esperienza nell'analisi delle vulnerabilit\u00e0 nei progetti Rust. Durante il controllo sono state riscontrate 113 problematiche di sicurezza. <\/p>\n
Attualmente \u00e8 disponibile un rapporto (PDF, 156 pagine) con i risultati della prima fase dell'audit, che copre le utility pi\u00f9 importanti del set uutils. Nella prima fase, condotta da dicembre 2025 a gennaio 2026, sono state rilevate 73 vulnerabilit\u00e0, di cui 7 classificate come critiche, 11 come pericolose, 29 come di media pericolosit\u00e0 e 26 come non pericolose. <\/p>\n
La seconda fase dell'audit \u00e8 stata condotta da febbraio a marzo e ha coperto le utility secondarie non esaminate nella prima fase. Nella seconda fase sono state trovate 40 vulnerabilit\u00e0, la cui pericolosit\u00e0 non \u00e8 ancora stata dettagliata (il rapporto verr\u00e0 pubblicato in seguito). Le informazioni su tutte le problematiche identificate sono gi\u00e0 state trasmesse agli sviluppatori di uutils e la maggior parte delle vulnerabilit\u00e0 \u00e8 stata risolta nelle versioni di uutils 0.5-0.8 senza eccessiva pubblicit\u00e0 e collegamenti ai correttivi apportati. <\/p>\n
Il pacchetto rust-coreutils \u00e8 stato incluso per impostazione predefinita nell'uscita autunnale di Ubuntu 25.10, ma in considerazione dei problemi riscontrati nell'audit, nella versione LTS di Ubuntu 26.04 sono stati ripristinati gli strumenti cp, mv e rm da GNU Coreutils. Si segnala che al 22 aprile in questi strumenti rimangono 8 stati di race condition noti non risolti. Le altre utility sono utilizzate dall'uscita rust-coreutils 0.8.0. In Ubuntu 26.10 gli sviluppatori intendono passare completamente a rust-coreutils. <\/p>\n
Le vulnerabilit\u00e0 nelle utility di sistema sono pericolose poich\u00e9 possono essere utilizzate negli script eseguiti con diritti di root. Ad esempio, la vulnerabilit\u00e0 risolta nella versione uutils coreutils 0.3.0 nell'utility rm poteva essere sfruttata durante l'esecuzione giornaliera tramite uno script cron \/etc\/cron.daily\/apport, che viene eseguito con diritti di root e elimina ricorsivamente il contenuto della cartella \/var\/crash, accessibile in scrittura a tutti gli utenti di sistema. <\/p>\n
Tra le vulnerabilit\u00e0 contrassegnate nel primo rapporto come critiche: <\/p>\n
\n
Vulnerabilit\u00e0 nell'utility chroot, causata dal trattamento dell'opzione \u00ab--userspec\u00bb dopo la chiamata di chroot(), ma prima del ripristino dei privilegi. Nei sistemi con glibc, la risoluzione dei nomi tramite la funzione getpwnam() porta alla lettura del file \/etc\/nsswitch.conf, utilizzato in NSS (Name Service Switch), e al caricamento dinamico delle librerie specificate con i moduli NSS (libnss_*.so.2). Poich\u00e9 prima del trattamento NSS viene eseguita la chiamata chroot(), il file \/etc\/nsswitch.conf viene caricato rispetto al nuovo root, ma le librerie NSS vengono caricate prima del ripristino dei privilegi. Se un utente ha accesso in scrittura al nuovo root, pu\u00f2 sostituire le proprie librerie NSS e ottenere l'esecuzione di codice con i privilegi di root.\n
Modifica dei permessi del file dopo il fallimento nella creazione di una named pipe (FIFO) da parte dell'utility mkfifo - se si specifica un file esistente come argomento, mkfifo restituir\u00e0 un errore, ma non terminer\u00e0 in modo anomalo; eseguir\u00e0 invece la chiamata a set_permissions() e cambier\u00e0 i permessi del file esistente. Considerando umask 022, la vulnerabilit\u00e0 consente di cambiare i permessi del file a 644 (rw-r--r--) e accedere a file per cui non era consentita la lettura.\n
Bypass delle restrizioni \u00ab--preserve-root\u00bb nell'utility chmod, che vietano l'esecuzione di operazioni ricorsive rispetto alla root del file system. La vulnerabilit\u00e0 (CVE-2026-35338) \u00e8 causata dal fatto che nel codice veniva verificata solo la corrispondenza esatta del percorso con \u00ab\/\u00bb e non veniva effettuata la canonizzazione del percorso del file. Per eludere il controllo \u00e8 sufficiente utilizzare un percorso del tipo \u00ab\/..\/\u00bb o un collegamento simbolico alla root. La vulnerabilit\u00e0 \u00e8 pericolosa poich\u00e9, se \u00e8 possibile sostituire il proprio percorso in uno script di sistema che chiama il comando chmod, si pu\u00f2 ottenere una modifica ricorsiva dei permessi per tutti i file nel file system.\n
Nell'utilit\u00e0 rm era consentito l'uso di qualsiasi abbreviazione dell'opzione \u00ab--no-preserve-root\u00bb (\u00ab-n\u00bb, \u00ab--no\u00bb, \u00ab--no-p\u00bb, \u00ab--no-pres\u00bb ecc.) per disattivare la protezione contro l'esecuzione di operazioni ricorsive dalla radice (ad esempio, \u00e8 possibile specificare \u00abrm -rf -n \/\u00bb e cancellare accidentalmente tutti i dati. In GNU Coreutils tali abbreviazioni di opzione sono vietate.\n
Eliminazione delle restrizioni \u00ab--preserve-root\u00bb nell'utilit\u00e0 rm, che vietano l'esecuzione di operazioni ricorsive relative alla radice del filesystem, tramite la sostituzione con un link simbolico a \u00ab\/\u00bb.\n
Mancanza di una protezione adeguata contro la specifica di directory che iniziano con un punto. Ad esempio, eseguendo \u00abrm -rf .\u00bb l'utilit\u00e0 restituir\u00e0 un errore, ma specificando \u00abrm -rf .\/*\u00bb o \u00abrm -rf .\/\/\/\u00bb eliminer\u00e0 silenziosamente la directory corrente.\n
Un errore nel codice di parsing degli argomenti dell'utilit\u00e0 kill consente di inviare un segnale a tutti i processi del sistema quando viene specificato l'identificativo del processo \u00ab-1\u00bb (kill -1). <\/ul>\n
Per il resto, la maggior parte delle vulnerabilit\u00e0 appartiene alla classe TOCTOU (Time-Of-Check-To-Time-Of-Use), che implica la presenza di una condizione di corsa che consente di modificare i dati nel momento successivo alla verifica della correttezza delle informazioni, ma prima dell'esecuzione dell'operazione, ad esempio, sostituendo un file con un link simbolico nel momento tra la conclusione della verifica e l'inizio dell'esecuzione dell'operazione. Nel contesto dell'uso delle utilit\u00e0 cp e mv in script di sistema eseguiti con privilegi di root, tali vulnerabilit\u00e0 consentono di copiare o sovrascrivere file arbitrari. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"