{"id":112924,"date":"2024-01-15T17:28:03","date_gmt":"2024-01-15T15:28:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-patchah-red-hat-k-zagruzchiku-grub2-pozvolyayushhaya-obojti-proverku-parolya"},"modified":"2024-01-15T17:28:03","modified_gmt":"2024-01-15T15:28:03","slug":"uyazvimost-v-patchah-red-hat-k-zagruzchiku-grub2-pozvolyayushhaya-obojti-proverku-parolya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/uyazvimost-v-patchah-red-hat-k-zagruzchiku-grub2-pozvolyayushhaya-obojti-proverku-parolya","title":{"rendered":"Vulnerabilit\u00e0 nei patch di Red Hat per il bootloader GRUB2 che consente di bypassare il controllo della password","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
\u00c8 emersa un'informazione riguardante la vulnerabilit\u00e0 (CVE-2023-4001) nei patch per il bootloader GRUB2, preparati da Red Hat. Questa vulnerabilit\u00e0 consente, su molti sistemi con UEFI, di bypassare il controllo della password impostata in GRUB2 per limitare l'accesso al menu di avvio o alla riga di comando del bootloader. La vulnerabilit\u00e0 \u00e8 causata da una modifica apportata da Red Hat al pacchetto contenente GRUB2 distribuito in RHEL e Fedora Linux. Il problema non si manifesta nel progetto principale di GRUB2 e interessa solo le distribuzioni che hanno applicato patch aggiuntive da Red Hat. <\/p>\n
Il problema \u00e8 causato da un errore nella logica di utilizzo dell'UUID per cercare il dispositivo di avvio con il file di configurazione (ad esempio, \u00ab\/boot\/efi\/EFI\/fedora\/grub.cfg\u00bb), che contiene l'hash della password. Per bypassare l'autenticazione, un utente con accesso fisico al computer pu\u00f2 collegare un'unit\u00e0 esterna, come una penna USB, impostando il suo UUID per replicare quello della partizione di avvio \/boot del sistema attaccato. <\/p>\n
Molti sistemi UEFI elaborano prima i supporti esterni e li pongono nella lista dei dispositivi rilevati prima degli hard disk interni, quindi la partizione \/boot preparata dall'attaccante avr\u00e0 una priorit\u00e0 maggiore nell'elaborazione. Di conseguenza, GRUB2 tenter\u00e0 di caricare il file di configurazione da questa partizione. Durante la ricerca della partizione tramite il comando \u00absearch\u00bb in GRUB2, viene determinata solo la prima corrispondenza dell'UUID, dopo di che la ricerca si ferma. Se il file di configurazione principale non viene trovato in una certa partizione, GRUB2 visualizzer\u00e0 un prompt dei comandi, consentendo di controllare completamente il processo di avvio successivo. <\/p>\n
Per determinare l'UUID della partizione, un utente locale non privilegiato pu\u00f2 utilizzare l'utilit\u00e0 \u00ablsblk\u00bb, ma un utente non autorizzato, che non ha accesso al sistema ma pu\u00f2 osservare il processo di avvio, in alcune distribuzioni potrebbe identificare l'UUID dai messaggi diagnostici visualizzati durante il caricamento. La vulnerabilit\u00e0 \u00e8 stata corretta da Red Hat tramite l'aggiunta di un nuovo argomento al comando \u00absearch\u00bb, che consente di limitare l'operazione di scansione dell'UUID solo ai dispositivi a blocchi utilizzati per avviare il bootloader (cio\u00e8, la partizione \/boot deve trovarsi sullo stesso disco della partizione di sistema EFI). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"