Link alla notizia: https://edge9.hwupgrade.it/news/security/il-fallout-nucleare-dell-incidente-crowdstrike-problemi-in-risoluzione-ma-la-vicenda-e-ancora-aperta_129120.html

Gli 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

Click sul link per visualizzare la notizia.

spettacolo.
parte della colpa è dell'UE? :rotfl:

sicuramente in MS sanno che anche Mac OS doveva "aprirsi" a terzi, e hanno implementato delle API apposite per permettere a suite di terzi di fare quello che fanno CrodwStrike e simili, senza dover scendere al livello così basso di interazione col kernel come invece ha scelto di fare MS.
e la colpa di questa scelta è dell'UE?
o era semplicemente la strada più veloce ed economica? :rolleyes:

spettacolo.
parte della colpa è dell'UE? :rotfl:

sicuramente in MS sanno che anche Mac OS doveva "aprirsi" a terzi, e hanno implementato delle API apposite per permettere a suite di terzi di fare quello che fanno CrodwStrike e simili, senza dover scendere al livello così basso di interazione col kernel come invece ha scelto di fare MS.
e la colpa di questa scelta è dell'UE?
o era semplicemente la strada più veloce ed economica? :rolleyes:

Microsoft ha perso l'ennesima occasione per rimanere in silenzio.

Tantopiù che questa volta non è un problema diretto dei suoi sistemi operativi ma di un software esterno.

Ma non c'è niente da fare...è più forte di loro ! :rolleyes:

Microsoft ha perso l'ennesima occasione per rimanere in silenzio.

Tantopiù che questa volta non è un problema diretto dei suoi sistemi operativi ma di un software esterno.

Ma non c'è niente da fare...è più forte di loro ! :rolleyes:

a quanto pare in USA è diventato obbligatorio dare la colpa all'UE.
anche Apple non è esente da questa modalità. basta vedere le novità di iOS18 e Mac OS Sequoia che non arriveranno in UE per via del DMA. almeno secondo Apple.
in UE non potremo fare il mirroring da iPhone sul Mac. cosa c'entri il DMA lo sa solo Apple.

ma questa di MS che dice che non hanno potuto dare l'accesso a SW di sicurezza di terzi se non al più basso livello di interazione col kernel per colpa dell'UE è spettacolare.

ma questa di MS che dice che non hanno potuto dare l'accesso a SW di sicurezza di terzi se non al più basso livello di interazione col kernel per colpa dell'UE è spettacolare.

hai delle prove che indichi che non si vero o è il tuo cugino che te lo dice?

spettacolo.
parte della colpa è dell'UE? :rotfl:

sicuramente in MS sanno che anche Mac OS doveva "aprirsi" a terzi, e hanno implementato delle API apposite per permettere a suite di terzi di fare quello che fanno CrodwStrike e simili, senza dover scendere al livello così basso di interazione col kernel come invece ha scelto di fare MS.
e la colpa di questa scelta è dell'UE?
o era semplicemente la strada più veloce ed economica? :rolleyes:

Hanno ragione. Sistemi di protezione del genere non li fai girare tramite "API apposite". Qualsiasi sistema simile deve aver accesso al kernel. Lo fanno anche tanti sistemi anticheat dei giochi (Vanguard di Riot per dirne uno famoso per essere 'root'). Se non sapete di cosa parlate tacete che fate più bella figura.
Detto questo, anche ci fossero state delle API, se uno carica un file *volontariamente* nel proprio sistema che ha bisogno del controllo totale per proteggere proattivamente, c'è poco da fare. Non è che tramite API non poteva essere scaricato un file sys problematico in una cartella. Il problema è la possibilità di poterlo caricare dopo semmai.

hai delle prove che indichi che non si vero o è il tuo cugino che te lo dice?

la prova è il fatto che Apple ha implementato l'Endpoint Security Framework (https://www.withsecure.com/en/expertise/resources/macos-endpoint-security-framework, https://research.meekolab.com/introduction-to-the-apple-endpoint-security-framework, ecc ecc) permettendo l'accesso ai SW di sicurezza di terzi senza incorrere in sanzioni/cause per concorrenza sleale o simili? e senza dover dare l'accesso a basso livello ai moduli del kernel (come invece faceva anche Apple con i moduli kext)?

forse, da un punto di vista tecnico, poteva essere fatto anche in Windows.
non certo in tempo 0, non certo dall'oggi al domani, ma dire che è colpa dell'UE se MS non ha potuto implementare altre soluzioni mi sembra, a conti fatti, un po' troppo tirata per i capelli.

Hanno ragione. Sistemi di protezione del genere non li fai girare tramite "API apposite". Qualsiasi sistema simile deve aver accesso al kernel. Lo fanno anche tanti sistemi anticheat dei giochi (Vanguard di Riot per dirne uno famoso per essere 'root'). Se non sapete di cosa parlate tacete che fate più bella figura.
Detto questo, anche ci fossero state delle API, se uno carica un file *volontariamente* nel proprio sistema che ha bisogno del controllo totale per proteggere proattivamente, c'è poco da fare. Non è che tramite API non poteva essere scaricato un file sys problematico in una cartella. Il problema è la possibilità di poterlo caricare dopo semmai.

ho risposto sopra con un paio di link da siti specializzati. non è certo il mio mestiere né mia competenza, ma da quello che si legge, quel framework fa esattamente quanto richiesto dai SW di sicurezza, senza avere accesso a basso livello al kernel.
quindi pare possibile.
che il framework sia "uguale" (=stessi risultati) ai vecchi moduli kext ovviamente non mi permetto di dirlo, ripeto, non è il mio campo.
non mi sembra, facendo qualche rapida ricerca, che i produttori di SW per il monitoraggi/sicurezza su Mac OS si siano lamentati di non poter più usare kext invece del framework.

la prova è il fatto che Apple ha implementato l'Endpoint Security Framework (https://www.withsecure.com/en/expertise/resources/macos-endpoint-security-framework, https://research.meekolab.com/introduction-to-the-apple-endpoint-security-framework, ecc ecc) permettendo l'accesso ai SW di sicurezza di terzi senza incorrere in sanzioni/cause per concorrenza sleale o simili? e senza dover dare l'accesso a basso livello ai moduli del kernel (come invece faceva anche Apple con i moduli kext)?

forse, da un punto di vista tecnico, poteva essere fatto anche in Windows.
non certo in tempo 0, non certo dall'oggi al domani, ma dire che è colpa dell'UE se MS non ha potuto implementare altre soluzioni mi sembra, a conti fatti, un po' troppo tirata per i capelli.

Parlare senza sapere le cose. Apple ha copiato quel sistema da Windows, che già lo aveva. Il bello è che te lo spiegano pure negli articoli che hai linkato.

"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/introduction-into-microsoft-threat-intelligence-drivers-etw-ti

Bravissima e spettacolare MS. :doh:
Nell'unico evento in cui non aveva colpe sostanziali, in cui era grossomodo una "vittima" della cattiva pubblicità attuale, è riuscita a capovolgere la situazione e rendersi ridicola.
Tanto di cappello.

Hanno ragione. Sistemi di protezione del genere non li fai girare tramite "API apposite". Qualsiasi sistema simile deve aver accesso al kernel. Lo fanno anche tanti sistemi anticheat dei giochi (Vanguard di Riot per dirne uno famoso per essere 'root'). Se non sapete di cosa parlate tacete che fate più bella figura.
Detto questo, anche ci fossero state delle API, se uno carica un file *volontariamente* nel proprio sistema che ha bisogno del controllo totale per proteggere proattivamente, c'è poco da fare. Non è che tramite API non poteva essere scaricato un file sys problematico in una cartella. Il problema è la possibilità di poterlo caricare dopo semmai.

Il problema vero in questo caso non stava nel dare "controllo totale" al kernel driver di Crowstrike ma nel non fare alcun controllo di integrità e in caso di errore non avere un fallback al riavvio successivo.

Poi 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.

Il problema vero in questo caso non stava nel dare "controllo totale" al kernel driver di Crowstrike ma nel non fare alcun controllo di integrità e in caso di errore non avere un fallback al riavvio successivo.

Poi 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.

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.

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à)

Parlare senza sapere le cose. Apple ha copiato quel sistema da Windows, che già lo aveva. Il bello è che te lo spiegano pure negli articoli che hai linkato.

"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/introduction-into-microsoft-threat-intelligence-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. :)

Ma è mai possibile che un device driver, caricando un suo modulo composto da tutti zeri binari (il famigerato update), possa crashare con un "null pinter exception" senza che il sistema operativo possa fare nulla per recuperare dal crash ?

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.

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 !

molto credibile lo statement crowdstrike che millanta n test prima di andare in produzione :stordita:

molto credibile lo statement crowdstrike che millanta n test prima di andare in produzione :stordita:

non millantano niente se poni n=0 l'equazione è rispettata :D :D