Posso presumere che la mia RAM non possa mai essere accessibile da un altro utente ad es. EC2 o Digital Ocean, se supponiamo che io mi fidi del mio provider e non consideriamo possibili bug (come Heartbleed) nel mio ambiente.
tl; dr: la RAM della macchina virtuale è ragionevolmente privata, date le tue ipotesi dichiarate.
Non sono un esperto di sicurezza delle macchine virtuali (veri esperti, per favore, correggi eventuali errori in questo post), ma ho trovato questa domanda abbastanza interessante da fare qualche ricerca su Google. Ecco cosa ho trovato.
Da una pubblicazione NIST intitolata Raccomandazioni di sicurezza per Distribuzione di hypervisor :
One of the common threats in virtualization platforms is a malicious VM accessing areas of memory belonging to other VMs. This is called a VM Escape attack. Processors with virtualization extensions provide safety against this through features such as Direct Memory Access (DMA) remapping limiting DMA access to what is valid for the VM (i.e., preventing a VM from performing DMA beyond its allocated area).
Questo paragrafo sta dicendo che la virtualizzazione con accelerazione hardware (che è praticamente la tutta virtualizzazione che incontrerai nel 2015) può imporre delle restrizioni all'accesso alla memoria piuttosto bene - almeno meglio della virtualizzazione solo software.
La carta NIST continua suggerendo quanto segue:
Security Recommendation HY-SR-6: The ratio of the combined configured memory of all VMs to the RAM memory of the virtualized host should not be very high. A typical ratio adopted is 1.5 : 1. In other words if a virtualized host has 64GB of RAM, then the combined configured memory of all VMs running on it should not exceed 96 GB.
Security Recommendation HY-SR-7: The hypervisor should have configuration options available to specify a guaranteed physical RAM for every VM (that requires it) along with a limit to this valu, and to specify a priority value for obtaining the required RAM resource in situations of contention among multiple VMs.
È probabile che gli host virtuali popolari, come EC2 e DigitalOcean, seguano queste linee guida per motivi di sicurezza e . Le loro macchine virtuali funzionerebbero piuttosto lentamente se sovrastassero la RAM. Tuttavia, per un host VM meno popolare, non saprei se hanno seguito le linee guida o meno. A seconda del carico di lavoro degli ospiti, l'host potrebbe ritenerlo redditizio.
Ora ricorda che l'host può sicuramente memorizzare lo stato della RAM, e qualsiasi tipo di vulnerabilità che consente l'esecuzione di codice arbitrario sull'host può comportare la lettura di contenuto arbitrario della VM VM.
Il documento NIST suggerisce anche una vulnerabilità in cui le immagini utilizzate per creare macchine virtuali sono compromesse, facendo sì che gli utenti VM girino su istanze già compromesse. Amazon e DigitalOcean probabilmente seguiranno anche qui le raccomandazioni NIST - che le immagini VM devono avere firme digitali valide e che le immagini per le nuove istanze non possono essere modificate da una macchina che esegue esistente istanze. Ancora una volta, un hypervisor cloud esaurito in qualche dormitorio del college potrebbe non avere una sicurezza equivalente sulle immagini.
L'intero documento del NIST vale la pena di leggerlo - non è molto lungo - e lo sono anche le seguenti domande su Stack:
tl: dr; In questo momento di scrittura, i contenitori in stile Docker non sono sicuri quanto gli hypervisor della macchina virtuale con accelerazione hardware.
In risposta a @grawity sulla mia altra risposta, questa risposta copre contenitori come Docker, che vengono utilizzati per eseguire applicazioni in modo simile alle macchine virtuali, ma i contenitori sono decisamente macchine non virtuali .
Qual è la differenza tra un contenitore e una macchina virtuale? Questo articolo Smartbear spiega (enfasi mia):
So why should you care about hypervisors vs. containers? Bottomley explains that hypervisors, such as Hyper-V, KVM, and Xen, all have one thing in common: “They’re based on emulating virtual hardware.” That means they’re fat in terms of system requirements.
[...]
Containers, on the other hand, are based on shared operating systems. They are much skinner and more efficient than hypervisors. Instead of virtualizing hardware, containers rest on top of a single Linux instance. This means you can “leave behind the useless 99.9% VM junk, leaving you with a small, neat capsule containing your application,” says Bottomley.
Come spiega la citazione NIST nella mia altra risposta, la virtualizzazione dell'hardware offre vantaggi in termini di sicurezza. Le piattaforme container eliminano tali benefici in cambio di aumenti delle prestazioni.
Solomon Hykes, il creatore del progetto Docker, ha scritto su Hacker News nell'estate 2014 che Docker non garantisce la sicurezza di ospiti non fidati:
Please remember that at this time, we don't claim Docker out-of-the-box is suitable for containing untrusted programs with root privileges. [...] When we feel comfortable saying that Docker out-of-the-box can safely contain untrusted uid0 programs, we will say so clearly.
È possibile configurare varie impostazioni di potenziamento della sicurezza, come indicato nelle linee guida per la sicurezza di Docker , ma la sicurezza viene ancora applicata dal software . Come afferma il documento NIST nella mia risposta, un hypervisor con accelerazione hardware utilizza l'hardware per prevenire gli attacchi di escape della VM, che riduce drasticamente la superficie di attacco di un ospite malintenzionato. Sebbene Docker possa avere funzionalità di sicurezza complete, ha semplicemente una superficie di attacco più grande.
L'analisi di Gartner del 2015 di Docker concorda , citando l'immaturità di Docker rispetto alle macchine virtuali tradizionali .
Al momento della stesura di questo documento, consiglierei alla sicurezza di non condividere host fisici con contenitori non fidati, né di eseguire contenitori non attendibili sulla vostra macchina fisica. Forse questo cambierà in futuro.
tl; dr: Sono possibili attacchi basati su cache per perdite di RAM. Farei attenzione ad avere una VM che spende il 100% del suo tempo di CPU facendo crittografia con chiavi segrete. Un utente malintenzionato può anche rallentare il tuo VM, il che potrebbe aiutare un possibile attacco con perdite di RAM. Inoltre, fai attenzione agli snapshot VM che catturano la tua RAM in esecuzione (la maggior parte dei servizi cloud non lo fa, però).
(So che avere tre risposte separate per la stessa domanda è un po 'ridicolo, ma rappresentano tre distinti treni di pensiero che sto cercando di combinare in un'unica risposta.)
Mi sono imbattuto in recensione di Thomas H. Ptacek sull'ingegneria della crittografia , e cita brevemente gli attacchi ai canali laterali su cloud di calcolo virtualizzati come Amazon EC2. Mr. Ptacek non ha elencato alcuna fonte o fornito esempi, ma ecco cosa ho imparato da un (ulteriore) pomeriggio su Google:
Un documento di aprile 2014 dell'Istituto di ricerca mobile di China che dimostra la creazione di un canale nascosto tra malware su due VM. Uno dei VM è fatto girare dall'attaccante, e l'altro è tuo. Ciò richiede che la tua macchina virtuale sia già compromessa , ma abilita un metodo di estrazione dei dati molto difficile da rilevare. Potresti monitorare la tua VM per traffico di rete in uscita malevolo ... ma staresti cercando nel posto sbagliato in quanto questo malware userebbe la contesa del bus di memoria per trasmettere fino a centinaia di kilobyte al secondo a VM dell'aggressore.
Un documento del 2014 del Worcester Polytechnic Institute descrive un attacco temporaneo cross-VM su AES . Gli autori di documenti si sono impegnati molto per assicurarsi che il loro attacco funzionasse in un realistico ambiente di cloud computing, il che rende i loro risultati piuttosto terrificanti. Gli autori sottolineano che la vulnerabilità è resa possibile dalla deduplicazione della memoria , che è una funzione di hypervisor che riduce l'utilizzo della memoria rilevando pagine duplicate. Questo è ottimo per le prestazioni, ma la deduplicazione è un modo intelligente per violare le linee guida NIST menzionato nella mia altra risposta e ti sovrastima la memoria.
Matthew Green ha un'eccellente analisi di un documento del 2012 che descrive gli attacchi del canale laterale cross-VM. L'attacco è più teorico, più difficile da attuare in pratica, e Amazon probabilmente avrà mitigato le vulnerabilità coinvolte da allora.
Un documento del 2010 descrive che il backup e il ripristino di istantanee di macchine virtuali possono indebolire un generatore di numeri casuali e causa perdita di dati. In questo caso, si applica solo ai guest della macchina virtuale con snapshot completi , che include la memoria attiva. Il documento afferma che i servizi cloud si basano su istantanee di volume, che includono solo il contenuto del disco, e non hanno indebolito i generatori di numeri casuali su un ripristino di istantanee.
Questo documento del 2009 da UCSD e MIT CSAIL è uno dei primi studi sugli attacchi ai canali laterali nel cloud computing. Direi (ma non sono sicuro) che la maggior parte degli attacchi attuali sono ormai tappati, ma la carta è una lettura notevole solo perché introduce vividamente la mentalità dell'attaccante.
Per quanto riguarda la tua domanda originale, nessuno di questi attacchi direttamente perde i dati . L'idea alla base di questi attacchi è che l'attaccante si limiti a rallentare la VM della vittima. Tuttavia, ho il sospetto che un attacco di rallentamento I / O possa essere usato da un avversario avanzato come parte di un più ampio attacco di furto di RAM. Per questo motivo, ho scelto di menzionarlo qui. Ho alcune idee su come utilizzare un attacco di rallentamento I / O per aiutare, ma non voglio speculare in modo errato.
I due documenti più rilevanti che ho trovato sono stati un documento del dicembre 2012 che propone vExplorer , un "framework di misurazione e analisi delle prestazioni VM I / O distribuito" che può essere utilizzato per eseguire attacchi basati su I / O "e un documento simile da George Washington University che descrive un framework chiamato Swiper .
Leggi altre domande sui tag memory shared-hosting