MicrosoftCrowdStrike
Il fallout nucleare dell'incidente CrowdStrike: problemi in risoluzione, ma la vicenda è ancora aperta
di Andrea Bai pubblicata il 23 Luglio 2024, alle 11:46 nel canale SecurityGli strascichi dell'incidente CrowdStrike sono pesanti per tutti: 8,5 milioni di sistemi colpiti, il CEO di Crowdstrike chiamato a testimoniare, i criminali informatici che approfittano dell'accaduto e Microsoft che incolpa la Commissione Europea
17 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - infoPoi c'è da aggiungere che DA ANNI Microsoft sta lavorando ad una sua implementazione degli eBPF già implementati su Linux che permettono di eseguire in maggior sicurezza codice di terze parti nel kernel, solo che non gli danno la priorità di sviluppo che invece riservano a cose tipo modifiche cosmetiche alla UI.
Micosoft ha lanciato ETW-TI nel 2022 proprio per evitare di dove injectare codice a livello kernel. La questione è un altra: se tu VOLONTARIAMENTE installi un software di questo tipo e ti crea un danno, è davvero colpa di MS?
Nel senso, perchè MS dovrebbe essere tenuta a controllare tutti i software del mondo e quello che fanno? Se qualcuno, *lecitamente*, vuole mettere mano da qualche parte, fosse anche il kernel, perchè dovrebbe impedirmelo? Qui non stiamo parlando di un malware, un virus o altro, ma un software autorizzato a fare quello che fa, e che anzi viene pagato apposta per fare quello che fa.
Il problema è della sw house, evidentemente il processo di release fa schifo se una cosa simile è riuscita ad andare in produzione ed essere distributa ovunque in questo modo. Cioè anche io nel mio piccolo, prima di fare un aggiornamento del genere, lo mando ad una ristretta cerchia di sistemi meno critici per vedere che succede. Di sicuro non faccio un install everywhere_in_the_world a prima botta... Qui sono mancate le più basilari regole di distribuzione del software, che è grave per di più per il tipo di software in questione.
Nel senso, perchè MS dovrebbe essere tenuta a controllare tutti i software del mondo e quello che fanno? Se qualcuno, *lecitamente*, vuole mettere mano da qualche parte, fosse anche il kernel, perchè dovrebbe impedirmelo? Qui non stiamo parlando di un malware, un virus o altro, ma un software autorizzato a fare quello che fa, e che anzi viene pagato apposta per fare quello che fa.
Il problema è della sw house, evidentemente il processo di release fa schifo se una cosa simile è riuscita ad andare in produzione ed essere distributa ovunque in questo modo. Cioè anche io nel mio piccolo, prima di fare un aggiornamento del genere, lo mando ad una ristretta cerchia di sistemi meno critici per vedere che succede. Di sicuro non faccio un install everywhere_in_the_world a prima botta... Qui sono mancate le più basilari regole di distribuzione del software, che è grave per di più per il tipo di software in questione.
grazie per le analisi, si evince come le maggiori libertà possono essere un bene (per esempio maggiore scelta in primisi) ma anche un male (per esempio maggiori casistiche di vulnerabilità
"Similar to Microsoft's approach in Windows via ETW-TI, ES provides a way for EDR/AV systems to run in user-mode privileges while still retaining the security and protection they enjoy running in kernel space."
Il problema è non dare proprio accesso a così basso livello. La stessa cosa è possibile anche su Mac.
PS: Nel caso te lo stessi chiedendo, Apple lo ha fatto nel 2024. MS lo ha dal 2022. Usando il tuo stesso sito: https://research.meekolab.com/intro...-drivers-etw-ti
grazie per la spiegazione. avevo letto troppo di fretta i link, trovandoli in effetti in un altro articolo dove anche lì non si faceva riferimento alla soluzione adottata da MS.
me culpa.
Microsoft lamenta che la unione europea ha imposto che vendor di terze parti possano installare driver in kernel mode (ring0), ma questo non significa che il sistema operativo non possa prendere precauzioni per fare "sandbox" degli stessi in caso di errori gravi! Qui si confondono alla base i "privilegi" con la "stabilità" del sistema.
Ne rimane, come amara conseguenza, un fatto incontestabile. Windows è estremamente fragile e privo di qualsivoglia recovery quando un suo modulo (o di altri partner) crea un errore software.
eh...
da windows 3 le bsod o altri eventi che impedivano il regolare avvio della macchina per delle "cagatine" tipo appunto driver et similia, ne ho visti parecchi !
non millantano niente se poni n=0 l'equazione è rispettata
Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".