Meltdown & Spectre - L'applicazione di patch al kernel guest di un hypervisor senza patch impedisce perdite di memoria tra VM?

12

24 ore dopo il rilascio su larga scala delle vulnerabilità, Rackspace tace su Spectre e Meltdown. Non hanno un piano per patchare tutti i loro hypervisor Xen. Tutti i loro server di piattaforma più recenti sono server HVM, che sono vulnerabili. I server FV meno recenti non sono vulnerabili.

Ho aggiornato il kernel Linux dei miei ospiti HVM, ma Rackspace non ha aggiornato nessuno dei loro hypervisor. L'aggiornamento del kernel guest su un hypervisor senza patch impedirà alle VM "cattive" di accedere alla memoria trapelata dal mio host con patch?

— Danny F
fonte

1

Vedi anche security.stackexchange.com/q/176709/11291

— Michael Hampton

12

Da quanto ho capito delle vulnerabilità, no: gli attacchi speculativi di memorizzazione nella cache ignorano tutte le protezioni della CPU contro un processo che cattura la memoria da qualsiasi indirizzo arbitrario.

Credo che ciò includerebbe le VM vicine (anche quelle patchate per proteggere dagli attacchi stessi) e lo spazio di memoria del kernel dell'hypervisor - ma anche se c'è qualcosa che mi manca che proteggerebbe dalla divulgazione diretta della memoria, c'è anche potenziale che l'attaccante potrebbe usare il proprio accesso alla memoria del kernel per ottenere un accesso più completo all'hypervisor.

Sicuramente non vuoi rischiare di eseguire un carico di lavoro sensibile su un hypervisor senza patch di qualsiasi tipo se non ti fidi di tutte le macchine virtuali in esecuzione su di esso.

— Shane Madden
fonte

6

Per dirla chiaramente: Avere un kernel ospite patch può impedire la tua VM di accedere al hypervisor o altre macchine virtuali, ma non impedirà altre macchine virtuali di accedere alla vostra!

— Michael Hampton

Ciao Shane, anche questa è la mia convinzione. Hai della documentazione per eseguire il backup? Il punto specifico sulla memoria di un guest con patch è vulnerabile ad altri guest sullo stesso hardware. Grazie.

— Danny F,

2

@DannyF Il riferimento più diretto a ciò che ho potuto trovare era nel documento di fusione : "memoria fisica di altri processi, il kernel e in caso di soluzioni sandbox di condivisione del kernel (ad esempio Docker, LXC) o Xen in modalità paravirtualizzazione, memoria del kernel (o hypervisor) e altre istanze situate "

— Shane Madden

-4

Spettro e fusione.

Da dove iniziamo? un cattivo, intendo un comunicato stampa molto brutto di qualcosa che può o meno influire sul tuo computer, workstation, server o server nel cloud. Sì, lo è, ma devi avere un accesso locale alla CPU associata, che potrebbe essere un PC o un telefono, sembra che Apple sia stata fatta un esempio, ma pensiamo alla sua CPU ARM, quindi è ogni piattaforma mobile che supporta la (funzione / esposizione microcodice / troppo controllo sulla CPU dal sistema operativo / etc / etc)

L'applicazione deve essere in esecuzione sulla CPU del dispositivo, quindi penso che l'accesso alla console, o almeno l'utente remoto che accede al sistema, immetta l'accesso al dispositivo ....

Al momento, l'unico modo noto per sfruttare queste vulnerabilità è l'accesso locale / diretto alla CPU (di nuovo può essere remoto una volta che si dispone di SSH / VNC ecc.)

Di seguito sono riportate le patch che ho trovato finora.

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm l

Ora questa deve essere la migliore risposta al problema in questo momento

Cosa hanno detto i nostri amici di BSD?

Bad google; (

un controllo Powershell per lo stesso;)

Il kernel Linux Ok, abbiamo trascorso una settimana interessante, e ormai tutti sanno perché stessimo unendo tutte quelle strane patch di isolamento della tabella delle pagine x86 senza seguire tutte le normali regole di temporizzazione del rilascio.

Posso / tornerò e modificare questo post. Sono sicuro che il non-problema (fino allo stato brado) non sarà un vero problema a lungo sterna. Google avrebbe davvero dovuto seguire le date di rilascio delle informazioni qui! -1 per Google

— Andrew Smalley
fonte

"Amazon Linux (AMI)" è la distribuzione Linux di Amazon, che è influenzata allo stesso modo di tutti gli altri sistemi operativi guest. Più rilevante in questo contesto è aws.amazon.com/de/security/security-bulletins/AWS-2018-013 (sezione iniziale) per l'annuncio EC2 (la loro piattaforma di virtualizzazione), poiché sembra che stiate cercando di elencare le soluzioni di virtualizzazione.

— Håkan Lindqvist

1

Leggendo e rileggendo questo, non credo che risolva effettivamente la domanda? Per lo più è solo un rant sul processo di divulgazione?

— Håkan Lindqvist

Apprezzo l'editoriale e i collegamenti per le correzioni, ma questa risposta è fuorviante o almeno confusa. Credo che indichi che lo scenario che ho descritto richiederebbe l'accesso locale all'hypervisor xenserver, il che non è vero. L'unico requisito è che il cattivo abbia la propria VM sullo stesso hypervisor della VM vittima.

— Danny F,