Visualizzazione dei risultati da 1 a 5 su 5
  1. #1
    Utente di HTML.it L'avatar di SkyLinx
    Registrato dal
    Jun 2017
    residenza
    Espoo, Finland
    Messaggi
    60

    Un'altra vulnerabilita' nelle CPU di Intel (e forse altri)

    Dopo Spectre, Meltdown, L1TF, eccone un'altra non correlata. Il fix suggerito e'... disabilitare HyperThreading, che significa anche per questa vulnerabilita' mitigare equivale a perdere prestazioni.

    https://www.zdnet.com/article/intel-...vulnerability/
    The only way to stay sane is to go a little crazy. - Susanna Kaysen

  2. #2
    Moderatore di Windows e software L'avatar di URANIO
    Registrato dal
    Dec 1999
    residenza
    Casalpusterlengo (LO)
    Messaggi
    1,250
    Ci sono gia in giro virus o simili in grado di sfuttare queste vulnerabilita?

  3. #3
    Utente di HTML.it L'avatar di Linkato
    Registrato dal
    Dec 2002
    Messaggi
    487
    Quote Originariamente inviata da SkyLinx Visualizza il messaggio
    Dopo Spectre, Meltdown, L1TF, eccone un'altra non correlata. Il fix suggerito e'... disabilitare HyperThreading, che significa anche per questa vulnerabilita' mitigare equivale a perdere prestazioni.

    https://www.zdnet.com/article/intel-...vulnerability/
    Non se ne può più, in che Mondo andremo a finire...

    Per non parlare della vulnerabilità del 4G dove un attaccante può praticamente clonare qualsiasi numero e re-indirizzare il traffico. Presente da mesi, non è stato ancora fixato.

    Ma quando il Mondo sarà interamente interconnesso con milioni di strumenti online ci rendiamo conto che probabilmente sarà un inferno sulla Terra?
    Primo Ministro Conte: "Sarà un anno bellissimo!"

  4. #4
    Io non capisco di cosa ci si stupisca. Questo tipo di problemi è chiaro che salti fuori nel momento in cui fornisci una CPU che abbia stato nascosto CPU-wide che impatta sulle prestazioni (pipeline, cache, branch predictor, execution unit shareate tra core diversi) e metodi precisi per misurare le prestazioni. Il peccato originale sta lì, tutto il resto sono mitigazioni che cercano di mettere un tappo a una nave che è comunque by design piena di buchi.

    Vuoi una CPU senza questi problemi? Comprati una MCU pensata per hard-realtime, in cui tutto è perfettamente deterministico e non c'è praticamente stato nascosto, ma poi non lamentarti che va tutto 20 volte più lento. Per quanto riguarda i miei casi d'uso, preferisco il tradeoff corrente - CPU con un sacco di birra ma che intrinsecamente hanno problemi di questo tipo.

    L'altra cosa che mi dà sui nervi è che sembra che questi problemi siano disastrosi e bisogna metterci una patch al più presto ovunque; in realtà di questa roba frega molto poco al consumer medio; nel momento in cui il browser (che è dove davvero gira codice untrusted di ogni genere) è più o meno al sicuro (e per quello almeno per ora sembra bastare una buona dose di jitter aggiunto all'orologio), su tutto il resto più o meno chissene frega. Alla fine su una macchina consumer gira codice sostanzialmente tutto di un utente, e la divisione tra codice kernel e codice user è utile sostanzialmente come difesa rispetto a bug (non vuoi che un'applicazione bacata qualunque ti tiri giù il sistema), non tanto per protezione di chissà che di valore. Non fatemi pagare il 30% di performance per syscall di "scassare apposta lo stato del branch predictor e smappare completamente le pagine kernel" per problemi che non mi riguardano.

    Per quanto riguarda VPS e in generale servizi cloud, "sucks to be you". Aggiustare una cosa del genere a basso livello e senza impattare le performance la vedo difficile, le cose ovvie che mi vengono in mente "ad alto livello" sono:
    - "rompere" il TSC per tutti gli host, rendendo molto più complicato fare misure di timing precise, critiche per questo tipo di exploit;
    - evitare in blocco di far condividere un core a processi/VM che non stanno nello stesso "security context"; se sullo stesso core hyperthreaded gira codice che sta già di suo nella stessa "gabbia" non c'è rischio di sicurezza;
    - spostare in blocco la parte di crittografia in "scatole sicure" (siano essi set di istruzioni dedicati non-leaking dal punto di vista delle performance come AES-NI, o coprocessori dedicati, o core dedicati solo a quello su cui gira solo codice fidato), e sperare che nessuno si metta a mirare ad estrarre dati dal tuo codice specifico.
    Ultima modifica di MItaly; 03-11-2018 a 13:25
    Amaro C++, il gusto pieno dell'undefined behavior.

  5. #5
    Utente di HTML.it L'avatar di SkyLinx
    Registrato dal
    Jun 2017
    residenza
    Espoo, Finland
    Messaggi
    60
    Quote Originariamente inviata da URANIO Visualizza il messaggio
    Ci sono gia in giro virus o simili in grado di sfuttare queste vulnerabilita?
    Puo' essere, ma almeno ufficialmente c'e' soltanto una PoC.


    Quote Originariamente inviata da Linkato Visualizza il messaggio

    Ma quando il Mondo sarà interamente interconnesso con milioni di strumenti online ci rendiamo conto che probabilmente sarà un inferno sulla Terra?
    Mai visto shodan.io?

    Per quanto riguarda VPS e in generale servizi cloud, "sucks to be you". Aggiustare una cosa del genere a basso livello e senza impattare le performance la vedo difficile
    Anche se non e' da escludere la possibilita' per es. di malware che attacchi l'utente comune, realisticamente parlando IMO l'unico ambito nel quale ci si deve preoccupare per davvero di queste vulnerabiilita' e' proprio quello dei VPS. Non solo per l'aspetto sicurezza ma anche per quello delle prestazioni e del relativo costo maggiore ... per chi ha migliaia di VMs da gestire e' una gran bella rottura di palle. Chissa' se questa roba sta' influenzando gli acquisti di dedicati invece che VPS/cloudVPS.
    The only way to stay sane is to go a little crazy. - Susanna Kaysen

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.