Finché una VM non esegue un codice non affidabile, no .
Si noti che "l'esecuzione di codice non attendibile" include l'assunzione di frammenti di codice da Github, StackOverflow o altrove e l'esecuzione in una sandbox di qualsiasi tipo, ad esempio: chroot , un contenitore isolato o virtuale macchina (tranne una sandbox del browser, come Brython o Emscripten, una volta che le corrette attenuazioni del browser sono state eseguite).
Se una VM può in ogni caso eseguire un codice non affidabile, la risposta è: dipende . È ancora possibile che non sia necessario tutto o nessuno dei le attenuazioni di un JS il motore ora presenta , ma il tuo modello di minaccia diventa molto più complicato.
A partire da ora, devono essere soddisfatti alcuni requisiti affinché la tua VM sia teoricamente esposta a Meltdown o agli effetti di Spectre:
-
La VM esegue un codice non affidabile che può, almeno, inviare messaggi al mondo esterno.
Inclusi, ma non limitati a, accesso a Internet o permessi per visualizzare o scrivere dati in un luogo che in un secondo momento potrebbe essere accessibile da un utente malintenzionato.
-
La VM consente l'utilizzo di timer o strumenti di alta precisione che potrebbero essere utilizzati per misurare i tempi di esecuzione relativi delle rispettive istruzioni del linguaggio di programmazione.
Inclusi, ma non limitati a, buffer condivisi tra thread concorrenti.
-
La VM presenta tecniche di ottimizzazione che, almeno in teoria, potrebbero consentire l'esecuzione del codice non affidabile con circa l'efficienza del codice compilato.
Compreso, ma non limitato a, compilazione just-in-time (JIT) o generazione bytecode ottimizzata.
Si ritiene [ citazione necessaria ] , che almeno in caso di CVE-2017-5715, in determinate circostanze (es. presenza di particolari sequenze di istruzioni binarie nel sistema biblioteche e una serie di eventi sfortunati), questo particolare requisito potrebbe essere ulteriormente rilassato o revocato.
-
È soddisfatta una delle seguenti condizioni:
- Le attenuazioni del sistema operativo per la fusione non vengono applicate
- La VM carica informazioni sensibili nello stesso processo in cui è possibile eseguire lo snippet di codice non attendibile
- Un utente malintenzionato può fornire un input in qualsiasi altro processo (che contiene informazioni sensibili nella sua memoria e viene eseguito sullo stesso sistema fisico su cui è in esecuzione il codice non affidabile) contemporaneamente mentre il codice non affidabile è in esecuzione, dal codice non attendibile stesso o con qualsiasi altro mezzo, direttamente o indirettamente
Se tutte e quattro le condizioni sopra sono vere, allora, teoricamente, la tua VM potrebbe essere utilizzata per estrarre informazioni sensibili dal tuo sistema, in base agli effetti di Spectre e / o Meltdown.
Un semplice esempio di una macchina virtuale che, sebbene efficacemente eseguendo spesso un codice di terze parti, non è esposta a Spectre è la VM del linguaggio hinting TrueType che non consente il threading o il timing delle istruzioni in alcun modo, rompendo, almeno, il requisito # 2.
An important note on system updates.
In case of Javascript PoC, Meltdown or Spectre aren't used to read either kernel memory or memory of other processes. They can be, but the main issue with Spectre in Javascript VM is that the VM runs in a sandbox (meant to be isolated and safe before) within a browser process which contains sensitive data (Web site passwords, cookies and so on).
OS updates (e.g. KPTI for Linux) won't help to mitigate the issue completely, because:
- They target Meltdown while the main issue is Spectre;
- The only thing KPTI guarantees is that a process wouldn't be able to read kernel memory (and memory of other processes mapped into kernel space, via Meltdown only). KPTI doesn't forbid a thread in a process from reading a memory which is, from the operating system point of view, available for the whole process to read, which is the case of passwords and cookies stored in the same browser process a JS sandbox runs in.
Inoltre, per essere accurato al cento per cento, hai chiesto se "mitigazioni simili" (a quelle JS VM) sono necessarie nelle VM per altre lingue. Si noti che una VM JS integrata nel browser dispone già di una sandbox complessiva ben progettata con accesso limitato a file system, IPC, linguaggio assembly e altre risorse di sistema. Nel caso in cui la tua VM (ad esempio una V8 JS VM che viene fornita con la piattaforma Node.js) abbia più permessi o abilità di una JS VM in-browser, potrebbe richiedere non simile , ma ulteriori e attenuazioni più rigorose.
A partire dal 14 gennaio 2018, questo è in teoria; ma la tua domanda è anche teorica.