{"id":100548,"date":"2021-06-20T10:22:54","date_gmt":"2021-06-20T08:22:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-v-yadre-linux-zatragivayushhaya-setevoj-protokol-can-bcm"},"modified":"2021-06-20T10:22:54","modified_gmt":"2021-06-20T08:22:55","slug":"uyazvimost-v-yadre-linux-zatragivayushhaya-setevoj-protokol-can-bcm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/uyazvimost-v-yadre-linux-zatragivayushhaya-setevoj-protokol-can-bcm","title":{"rendered":"Vulnerabilit\u00e0 nel kernel Linux che colpisce il protocollo di rete CAN BCM","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Nel kernel Linux \u00e8 stata identificata una vulnerabilit\u00e0 (CVE-2021-3609) che consente a un utente locale di elevare i propri privilegi nel sistema. Il problema \u00e8 causato da una condizione di gara nell'implementazione del protocollo CAN BCM e si manifesta nelle versioni del kernel Linux da 2.6.25 a 5.13-rc6. Nei vari distribuzioni, la problematica rimane irrisolta (RHEL, Fedora, Debian, Ubuntu, SUSE, Arch). <\/p>\n
Il ricercatore che ha scoperto la vulnerabilit\u00e0 \u00e8 riuscito a preparare un exploit per ottenere i diritti di root sui sistemi con kernel Linux 5.4 e versioni successive, dimostrando anche la possibilit\u00e0 di un attacco riuscito su Ubuntu 20.04.02 LTS. Non si esclude la possibilit\u00e0 di adattare l'exploit per lavorare anche con versioni pi\u00f9 vecchie del kernel (nel kernel 5.4, il codice CAN BCM (net\/can\/bcm.c) \u00e8 stato convertito da hrtimer_tasklet a HRTIMER_MODE_SOFT). <\/p>\n
Il protocollo CAN BCM consente di registrare un proprio gestore di messaggi in arrivo tramite il bus CAN (controller area network) e di associarlo a un socket di rete specifico. Quando arriva un messaggio in ingresso, viene chiamata la funzione bcm_rx_handler(). L'attaccante pu\u00f2 sfruttare la condizione di gara per chiudere il socket di rete contemporaneamente all'esecuzione di bcm_rx_handler(). Quando il socket viene chiuso, viene chiamata la funzione bcm_release(), che libera la memoria allocata per le strutture bcm_op e bcm_sock, che continuano per\u00f2 a essere utilizzate nel gestore bcm_rx_handler() ancora in esecuzione. Si verifica quindi una situazione che porta a un accesso a un blocco di memoria gi\u00e0 liberato (use-after-free). <\/p>\n
L'attacco consiste nell'aprire due socket CAN BCM e collegarli all'interfaccia vcan. Nel primo socket viene effettuata una chiamata sendmsg() con il flag RX_SETUP per configurare il gestore dei messaggi CAN in arrivo, mentre nel secondo socket viene effettuata una chiamata sendmsg() per inviare un messaggio al primo socket. Dopo la ricezione del messaggio, viene attivata la chiamata bcm_rx_handler(), e l'attaccante individua il momento opportuno per chiudere il primo socket, il che porta all'attivazione di bcm_release() e alla liberazione delle strutture bcm_op e bcm_sock, sebbene il lavoro di bcm_rx_handler() non sia ancora terminato. <\/p>\n
Attraverso manomissioni del contenuto di bcm_sock, un attaccante pu\u00f2 ridefinire il puntatore alla funzione sk->sk_data_ready(sk), reindirizzare l'esecuzione e, mediante tecniche di programmazione orientata al ritorno (ROP - Return-Oriented Programming), organizzare la riscrittura del parametro modprobe_path per eseguire il proprio codice con i privilegi di root. Utilizzando la tecnica ROP, l'attaccante non cerca di posizionare il proprio codice in memoria, ma opera su frammenti di istruzioni di macchina gi\u00e0 esistenti nelle librerie caricate, che terminano con un'istruzione di ritorno al controllo (di solito si tratta delle conclusioni delle funzioni di libreria). Il funzionamento dell'exploit si riduce alla costruzione di una catena di chiamate a tali blocchi (' gadget') per ottenere la funzionalit\u00e0 desiderata.
<\/center> <\/p>\n
Per l'attacco \u00e8 necessario avere accesso per creare socket CAN e un'interfaccia di rete vcan configurata. I diritti necessari per effettuare l'attacco possono essere ottenuti da un utente non privilegiato in contenitori creati in sistemi con il supporto attivato per gli spazi dei nomi degli identificatori utente (user namespaces). Ad esempio, gli user namespaces sono abilitati per impostazione predefinita in Ubuntu e Fedora, ma non sono attivati in Debian e RHEL. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Vulnerabilit\u00e0](\"\/wp-content\/uploads\/2021\/06\/60534f0194a819c8401abf2ec53b3a9a.png\")
<\/center> <\/p>\n