Spectre e Meltdown, due bug di sicurezza che sconvolgono il mondo dell'informatica

[Erotavlas_turbo]

Originariamente inviato da Mparlav

Anche IBM Power 8 e 9:
https://access.redhat.com/security/v...ativeexecution
http://www-01.ibm.com/support/docvie...id=swg22012320
https://www.ibm.com/blogs/psirt/pote...-power-family/

Grazie per la segnalazione, non avevo considerato CPU per mainframe e quelle poco diffuse.

[tallines]

Il furbetto del quartierino.....Brian Krzanich amministratore delegato di Intel, avendo già capito che le azioni sarebbero andate giù..........ehhh sai com' è, gli seccava perdere soldi........poverino.....

E non si è dimesso ?

O non sapeva nulla di questa storia...........?

Che impieghi i soldi che ha preso dalla vendita, per risolvere il problema, invece!

Ma che poi, questi che hanno dato vita a Meltdown e Spectre, non hanno null' altro da fare nella vita...........

Un problema non da poco...........se penso a tutti i computer usati al mondo in ambito privato e pubblico, banche compre.................

Meltdown and Spectre

Bugs in modern computers leak passwords and sensitive data.

[SkyLinx]

Originariamente inviato da Sandro kensan

Segnalo il primo POC:

http://cxsecurity.com/issue/WLB-2018010039

Spectre Information Disclosure Proof Of Concept

In particolare mi pare che acceda a un array tramite una misurazione di tempo (latenza):

time1 = __rdtscp(&junk); /* READ TIMER */
junk = *addr; /* MEMORY ACCESS TO TIME */
time2 = __rdtscp(&junk) - time1; /* READ TIMER & COMPUTE ELAPSED TIME */

C'ho capito poco ma mi pare che misurando il tempo riesca ad accedere a un array

Qui spiegano un po' cosa c'entra il timing https://www.raspberrypi.org/blog/why...e-or-meltdown/

[MaxFabio93]

Capendo l'enorme portata dei possibili problemi che questi bug potrebbero causare a milioni di PC in tutto il mondo, specialmente quelli equipaggiatti con hardware Intel vedo tantissima, troppa confusione sull'argomento e troppo allarmismo ingiustificato da chi dovrebbe dormire tranquillo e sereno.

Vedo troppi generalizzare il problema mentre è Intel a doverne pagare in maggioranza le conseguenze, visto che il bug affligge i suoi processori, in misura molto minore AMD e AMR.

Poi come al solito ci si fa prendere dal panico quando basta tenere sotto controllo il proprio dispositivo e non dare autorizzazioni e accessi random a tutto e a tutti.

Originariamente inviato da Erotavlas_turbo

Non è esattamente cosi. Intel è coinvolta molto di più di AMD e ARM.
I dettagli dei due bug sono spiegati bene anche con video esempi qui https://spectreattack.com/. Meltdown che impatta sulle prestazioni (agisce tra sistema operativo e applicazioni) e Spectre che non impatta sulle prestazioni (agisce tra applicazioni). Al momento solo Intel è vulnerabile ad entrambi i bug e questa è la lista delle architetture di CPU coinvolte https://security-center.intel.com/ad...nguageid=en-fr mentre AMD https://www.amd.com/en/corporate/speculative-execution e ARM https://developer.arm.com/support/security-update sono vulnerabili solo a Spectre. In particolare, Intel è vulnerabile a tutte e tre le varianti, ARM solo a due mentre AMD solo a una. Indipendentemente dal calo prestazionale che ci potrà essere, la domanda è: chi ha volutamente messo questi bug nei processori (NSA, CIA)? Come è possibile che Intel non se ne sia accorta in 20 anni?
Occorrono CPU e hardware in generale open source a partire dal firmware. Avanti tutta con i progetti coreboot e libreboot che permettono di escludere anche l'altro problema delle CPU Intel https://libreboot.org/faq.html#intel e in parte di quelle AMD https://libreboot.org/faq.html#amd.

Interessante, grazie per le risorse e le fonti Comunque non griderei al complotto ma piuttosto mi chiederei dove è finita tutta la sicurezza di cui parlava Intel.

[ulukaii]

Originariamente inviato da tallines

Il furbetto del quartierino.....Brian Krzanich amministratore delegato di Intel, avendo già capito che le azioni sarebbero andate giù..........ehhh sai com' è, gli seccava perdere soldi........poverino.....

E non si è dimesso ?

O non sapeva nulla di questa storia...........?

Che impieghi i soldi che ha preso dalla vendita, per risolvere il problema, invece!

Ma che poi, questi che hanno dato vita a Meltdown e Spectre, non hanno null' altro da fare nella vita...........

Un problema non da poco...........se penso a tutti i computer usati al mondo in ambito privato e pubblico, banche compre.................

Meltdown and Spectre

Bugs in modern computers leak passwords and sensitive data.

Un po' difficile da credere, visto alcune compagnie AV che dovevano rilasciare conformità con l'update "fixa Meltdown" di Windows (previsto sulla carta per il 9 gennaio) avevano annunciato se fosse o meno compatibile (la famosa chiave di conformità nel registro) già durante lo scorso dicembre.

Esempio, questo è l'annuncio di compatibilità dei prodotti Kaspersky rilasciato il 29 dicembre, dove riporta cosa sarebbe stato compatibile (e cosa no) con l'update del 9 gennaio, con relative date. Quindi è abbastanza ingenuo pensare che Intel non sapesse di nulla, tanto meno il suo CEO

[Marco71]

...non dominabile evidentemente nemmeno da "team" di molte persone, progettisti, scienziati ecc. ecc. e non nel settore dei processori per calcolatori-computer di fatto delle enormi macchine a stati finiti.
Questo è un problema nel microcodice dei K8 e K10 AMD ad esempio...e chissà quanti altri ancora ne esistono latenti...

https://hackaday.com/2017/12/28/34c3-hacking-into-a-cpus-microcode/

Marco71.

[cdimauro]

Originariamente inviato da Erotavlas_turbo

Indipendentemente dal calo prestazionale che ci potrà essere, la domanda è: chi ha volutamente messo questi bug nei processori (NSA, CIA)? Come è possibile che Intel non se ne sia accorta in 20 anni?

Perché se implementi una cosa e funziona, e si tratta di roba che non cambia nel tempo (parliamo del meccanismo di funzionamento della memoria virtuale, che è codificato ormai da parecchi anni), allora non ci rimetti mano a meno che non trovi, per l'appunto, un errore.

Quindi niente complottismo: si tratta "semplicemente" di una cosa che è diffusa tanto quanto i calcoli elettronici. I famigerati "bug"...

Occorrono CPU e hardware in generale open source a partire dal firmware. Avanti tutta con i progetti coreboot e libreboot che permettono di escludere anche l'altro problema delle CPU Intel https://libreboot.org/faq.html#intel e in parte di quelle AMD https://libreboot.org/faq.html#amd.

Che non risolvono assolutamente le problematiche di cui parla la notizia.

Non è che basta appiccicare la parola "open" su qualcosa per conferirgli un'aura di sicurezza...

[cdimauro]

Originariamente inviato da MaxFabio93

Capendo l'enorme portata dei possibili problemi che questi bug potrebbero causare a milioni di PC in tutto il mondo, specialmente quelli equipaggiatti con hardware Intel vedo tantissima, troppa confusione sull'argomento e troppo allarmismo ingiustificato da chi dovrebbe dormire tranquillo e sereno.

Vedo troppi generalizzare il problema mentre è Intel a doverne pagare in maggioranza le conseguenze, visto che il bug affligge i suoi processori, in misura molto minore AMD e AMR.

Poi come al solito ci si fa prendere dal panico quando basta tenere sotto controllo il proprio dispositivo e non dare autorizzazioni e accessi random a tutto e a tutti.

Interessante, grazie per le risorse e le fonti Comunque non griderei al complotto ma piuttosto mi chiederei dove è finita tutta la sicurezza di cui parlava Intel.

E dov'è la sicurezza di AMD e ARM, visto che pure loro sono afflitte da vulnerabilità?

[Marco71]

...assoluta per ciò che viene prodotto da menti umane limitate, incapaci di andare oltre progetti di una certa complessità in ogni settore dello scibile non esiste.
Le cpu con esecuzione fuori ordine sono un esempio...e non solo quelle progettate da Intel...tutte...
Se fosse vivo il buon Tomasulo darebbe calci nel lato b alle seguenti generazioni nuove generazioni di progettisti.

Marco71.

[tallines]

Originariamente inviato da Erotavlas_turbo

Non è esattamente cosi. Intel è coinvolta molto di più di AMD e ARM.
I dettagli dei due bug sono spiegati bene anche con video esempi qui https://spectreattack.com/. Meltdown che impatta sulle prestazioni (agisce tra sistema operativo e applicazioni) e Spectre che non impatta sulle prestazioni (agisce tra applicazioni). Al momento solo Intel è vulnerabile ad entrambi i bug e questa è la lista delle architetture di CPU coinvolte https://security-center.intel.com/ad...nguageid=en-fr mentre AMD https://www.amd.com/en/corporate/speculative-execution e ARM https://developer.arm.com/support/security-update sono vulnerabili solo a Spectre. In particolare, Intel è vulnerabile a tutte e tre le varianti, ARM solo a due mentre AMD solo a una.

Indipendentemente dal calo prestazionale che ci potrà essere, la domanda è: chi ha volutamente messo questi bug nei processori (NSA, CIA)? Come è possibile che Intel non se ne sia accorta in 20 anni?

Occorrono CPU e hardware in generale open source a partire dal firmware. Avanti tutta con i progetti coreboot e libreboot che permettono di escludere anche l'altro problema delle CPU Intel https://libreboot.org/faq.html#intel e in parte di quelle AMD https://libreboot.org/faq.html#amd.

Interessante, grazie per averlo postato

Ho evidenziato AMD perchè ho come processore AMD e la domanda, perchè è il centro di tutto.........questo scombussolamento mondiale..........

Io non ho nessun calo prestazione, il SO è veloce come prima, W10 Fall Creators Update 1709 build 16299.192 .

Che poi a parte il calo di prestazioni....il problema sono i famosi dati.......

Originariamente inviato da ulukaii

Un po' difficile da credere, visto alcune compagnie AV che dovevano rilasciare conformità con l'update "fixa Meltdown" di Windows (previsto sulla carta per il 9 gennaio) avevano annunciato se fosse o meno compatibile (la famosa chiave di conformità nel registro) già durante lo scorso dicembre.

Esempio, questo è l'annuncio di compatibilità dei prodotti Kaspersky rilasciato il 29 dicembre, dove riporta cosa sarebbe stato compatibile (e cosa no) con l'update del 9 gennaio, con relative date. Quindi è abbastanza ingenuo pensare che Intel non sapesse di nulla, tanto meno il suo CEO

Infatti la domanda è messa per dire, che sapeva tutto

[cdimauro]

Originariamente inviato da Marco71

...assoluta per ciò che viene prodotto da menti umane limitate, incapaci di andare oltre progetti di una certa complessità in ogni settore dello scibile non esiste.
Le cpu con esecuzione fuori ordine sono un esempio...e non solo quelle progettate da Intel...tutte...

*

Se fosse vivo il buon Tomasulo darebbe calci nel lato b alle seguenti generazioni nuove generazioni di progettisti.

Marco71.

Il problema, come avevo già evidenziato nell'altro thread, è che vogliamo CPU con prestazioni sempre migliori. E finisce che poi ne paghiamo le conseguenze.

[yeppala]

Questi bug potrebbero segnare la fine dell'informatica
=> Tutti ad arare i campi di grano!

[cdimauro]

O la fortuna per l'informatico che magari riesce a risolverne qualcuna.

[MaxFabio93]

Originariamente inviato da cdimauro

E dov'è la sicurezza di AMD e ARM, visto che pure loro sono afflitte da vulnerabilità?

Prima di tutto AMD e ARM hanno minori vulnerabilità rispetto ai processori Intel, secondo la stessa Intel rimarca sempre con forza la sicurezza e i controlli nei suoi prodotti, cosa che evidentemente non è stata fatta a sufficienza visto che i danni sono maggiormente li. Se poi è vero che la cosa si conosceva da anni...tutto nascosto a discapito come sempre degli utenti.

[Sandro kensan]

Originariamente inviato da SkyLinx

Qui spiegano un po' cosa c'entra il timing https://www.raspberrypi.org/blog/why...e-or-meltdown/

Sì, l'esempio è chiaro in tutte le sue parti. Però quello è l'esempio del Meltdown mentre il mio è del Spectre. Comunque se tu od altri avete capito Meltdown allora vi siete chiesti se forse per risolvere il problema quell'istruzione di accesso alla kernel memory dell'esempio:

w = kern_mem[address] # if we get here crash

dovesse essere eseguita in maniera *non* speculativa? Questo perché non appartiene al set di istruzioni permesse dalla modalità utente, quindi non doveva essere riempito il registro w_ e neppure x_ e neppure doveva esserci l'accesso alla memoria user_mem[x_].

Con questo vincolo il programma sarebbe diventato:

t = a+b
u = t+c
v = u+d
if v:
   w = kern_mem[address]   # if we get here crash
   x = w&0x100
   y = user_mem[x]

senza alcuna possibilità di out of order e di esecuzione speculativa e cioè non sarebbe stato eseguita la micidiale:

t, w_ = a+b, kern_mem[address]
u, x_ = t+c, w_&0x100
v, y_ = u+d, user_mem[x_]

if v:
   # crash
   w, x, y = w_, x_, y_      # we never get here

Concordi?

[ziobeppe7]

Originariamente inviato da yeppala

Questi bug potrebbero segnare la fine dell'informatica
=> Tutti ad arare i campi di grano!

Troppo ottimista: per arare i campi ci vuole troppa tecnologia! Io direi al massimo di zappare e vangare

[cdimauro]

Originariamente inviato da Bellaz89

Oggi email apocalittiche dalla divisione sistemi informatici

EDIT: da noi è particolarmente problematico. Ci sono un sacco di sistemi vecchi che pilotano ancora Delle macchine. Per dire... Oggi lavoravo vicino a una Sparc Station coperta da una spanna di polvere con il compito di controllare qualche attuatore e a un terminale con winxp a controllare un amplificatore RF.

Il problema più grosso è se per questi vecchi s.o. verranno rilasciati o meno aggiornamenti con le patch.

XP, come sappiamo, non è più supportato da anni. Per Sparc non ho idea.

Originariamente inviato da MaxFabio93

Prima di tutto AMD e ARM hanno minori vulnerabilità rispetto ai processori Intel,

Quindi hanno anche loro problemi di sicurezza. Mal comune, per l'appunto.

secondo la stessa Intel rimarca sempre con forza la sicurezza e i controlli nei suoi prodotti,

Non conosco aziende che affermino che i loro prodotti non siano sicuri. Se conosci qualcuna, gradirei un link a una pagina o documento, giusto per prenderne visione.

cosa che evidentemente non è stata fatta a sufficienza visto che i danni sono maggiormente li.

Lì dove? Non è chiaro cosa vorresti dire.

Se poi è vero che la cosa si conosceva da anni...tutto nascosto a discapito come sempre degli utenti.

Senza alcuna prova (e almeno non emerso proprio nulla), questo è il classico complottismo spicciolo.

Ho già affermato che non ha alcun senso per un'azienda come Intel, che sforna 400 MILIONI (MI-LI-O-NI) l'anno, di tenersi nella pancia un problema di sicurezza di questa portata, senza porvi alcun rimedio, col rischio di potersi beccare denunce e class action.

Soltanto i complottisti, che non sono in grado di usare nemmeno un pallottoliere per fare dei conti della serva così banali, possono sostenere una tesi del genere.

[cdimauro]

Originariamente inviato da Sandro kensan

Sì, l'esempio è chiaro in tutte le sue parti. Però quello è l'esempio del Meltdown mentre il mio è del Spectre. Comunque se tu od altri avete capito Meltdown allora vi siete chiesti se forse per risolvere il problema quell'istruzione di accesso alla kernel memory dell'esempio:

w = kern_mem[address] # if we get here crash

dovesse essere eseguita in maniera *non* speculativa? Questo perché non appartiene al set di istruzioni permesse dalla modalità utente, quindi non doveva essere riempito il registro w_ e neppure x_ e neppure doveva esserci l'accesso alla memoria user_mem[x_].

Con questo vincolo il programma sarebbe diventato:

t = a+b
u = t+c
v = u+d
if v:
   w = kern_mem[address]   # if we get here crash
   x = w&0x100
   y = user_mem[x]

senza alcuna possibilità di out of order e di esecuzione speculativa e cioè non sarebbe stato eseguita la micidiale:

t, w_ = a+b, kern_mem[address]
u, x_ = t+c, w_&0x100
v, y_ = u+d, user_mem[x_]

if v:
   # crash
   w, x, y = w_, x_, y_      # we never get here

Concordi?

Senza esecuzione OoO ovviamente il problema non si pone, perché l'eccezione verrebbe sollevata immediatamente.

Ma il problema è un altro: è l'accesso ai dati della cache caricati speculativamente. E' questo che dev'essere risolto.

Ovviamente separando completamente gli spazi d'indirizzamento di kernel e user land, si risolve il problema a monte. Ma con un costo prestazionale che al momento sembra abbastanza ridotto.

[Sandro kensan]

Originariamente inviato da cdimauro

Senza esecuzione OoO ovviamente il problema non si pone, perché l'eccezione verrebbe sollevata immediatamente.

Ma il problema è un altro: è l'accesso ai dati della cache caricati speculativamente. E' questo che dev'essere risolto.

L'esempio linkato da SkyLinx è proprio relativo ai dati della cache elaborati speculativamente. Tali dati sono sia di tipo privilegiato che non. La mia idea è che se i dati sono di tipo non privilegiato allora possono essere elaborati speculativamente ma se sono dati privilegiati allora si blocca la speculatività.

E in effetti l'esempio linkato non avrebbe problemi se fosse seguita la pratica della mia idea.

Originariamente inviato da cdimauro

Ovviamente separando completamente gli spazi d'indirizzamento di kernel e user land, si risolve il problema a monte. Ma con un costo prestazionale che al momento sembra abbastanza ridotto.

Immagino che in questo caso non venga eseguita l'istruzione speculativa:

t, w_ = a+b, kern_mem[address]

[cdimauro]

Originariamente inviato da Sandro kensan

L'esempio linkato da SkyLinx è proprio relativo ai dati della cache elaborati speculativamente. Tali dati sono sia di tipo privilegiato che non.

Esattamente.

La mia idea è che se i dati sono di tipo non privilegiato allora possono essere elaborati speculativamente ma se sono dati privilegiati allora si blocca la speculatività.

E in effetti l'esempio linkato non avrebbe problemi se fosse seguita la pratica della mia idea.

In realtà si potrebbe fare altro. Il tuo sarebbe un caso particolare, mentre problematiche di questo tipo ce ne sono diverse, che non verrebbero risolte con la tua idea.

Serve una soluzione più generale al problema.

Immagino che in questo caso non venga eseguita l'istruzione speculativa:

t, w_ = a+b, kern_mem[address]

No, in questo caso, non essendo mappata alcuna memoria del kernel, è proprio impossibile accedervi. Dunque non esisterebbe nessuna kern_mem[address]: tutta la memoria che il processo vede è solo ed esclusivamente sua.

Ecco perché con la separazione degli spazi d'indirizzamento di kernel e user land, il problema è risolto proprio a monte.