OpenGL è un problema di sicurezza?

16

Oggi, quasi tutti i sistemi operativi e i dispositivi desktop e portatili supportano alcune versioni di OpenGL. Mi sto interrogando sulle implicazioni di sicurezza di questo:

  • In molti casi, la GPU ha accesso completo e illimitato alla memoria principale (per i dispositivi grafici integrati) o almeno alla RAM video, dove potrebbero essere archiviate anche informazioni sensibili (pensa ai gestori di finestre di compositing o ai browser web con accelerazione hardware) .
  • In alcune implementazioni, i client OpenGL comunicano con la GPU scrivendo direttamente dati e comandi nella memoria condivisa.
  • Solo le GPU recenti sembrano supportare la virtualizzazione della memoria e, anche in questo caso, solo alcune implementazioni dei driver la stanno attualmente utilizzando.
  • WebGL richiede che gli oggetti buffer appena allocati siano inizializzati a zero; Sospetto che ciò significhi che questo non è richiesto in OpenGL standard. Ciò significa che è teoricamente possibile allocare un buffer nella memoria video e leggere i dati potenzialmente sensibili alla sicurezza?

Quindi chi o cosa mi impedisce di scrivere un programma shader che legge i dati nel video o anche la memoria principale che non mi appartiene?

Ho trovato una presentazione sullo stato attuale delle cose nel sistema grafico Linux che menziona che sia i comandi alla GPU sono verificati dal kernel, o quella memoria virtuale viene utilizzata sulla GPU per separare gli utenti.

Questo vale anche per altri sistemi operativi, specialmente mobili, come Android, in cui le singole applicazioni sono strongmente in sandbox, ma hanno accesso OpenGL quasi illimitato? Tegra 2 è anche menzionato specificamente in quella presentazione per consentire un accesso potenzialmente illimitato alla memoria degli utenti del driver.

    
posta lxgr 09.05.2013 - 15:58
fonte

2 risposte

3

Per una sicurezza adeguata, le schede grafiche devono essere trattate come tutti gli altri tipi di hardware che hanno accesso alla RAM: devono venire sotto l'ombrello di MMU e l'utilità di pianificazione controllata dal kernel, in modo che l'esecuzione simultanea delle attività non possa influire l'una sull'altra e possa interagire solo attraverso canali di comunicazione gestiti con cura dal kernel.

Come si nota, tale isolamento e condivisione per i controller grafici 3D è solo una funzione recente. Per la maggior parte dei due decenni precedenti, la grafica 3D accelerata è stata una strada aperta alle vulnerabilità ... che si è rivelata essere sfruttata molto raramente, per i seguenti motivi:

  • Sulla maggior parte dei sistemi (Windows, Linux ...), l'accesso alla scheda 3D è autorizzato solo agli utenti che siedono davanti alla macchina, sulla base del fatto che un'animazione 3D fluida non è sufficiente la rete comunque. Le persone malvagie che hanno accesso fisico alla macchina hanno all'interno del sistema dei percorsi di ingresso molto più efficienti di quelli con la GPU.

  • Affrontare i dettagli di basso livello della GPU è un compito arduo, soprattutto perché molti di essi non sono documentati (ecco perché i driver proprietari sono ancora utilizzati in Linux). Gli aggressori sono anche esseri umani, quindi intrinsecamente pigri.

Le piattaforme di sandboxing come gli smartphone potrebbero cambiarlo, perché ospitano applicazioni che possono accedere all'hardware 3D e tuttavia essere ostili tra loro. Ma perché dovrebbero preoccuparsene? È molto più semplice chiedere diritti di accesso estesi al momento dell'installazione (l'utente dice semplicemente sì a tutti comunque).

    
risposta data 10.05.2013 - 04:43
fonte
8

Ho eseguito alcuni esperimenti su Linux e varie GPU e driver. Ho seguito un tutorial di base OpenGL per il mapping delle texture e ho sostituito il puntatore ai dati di texture nella chiamata a glTexImage2D con un puntatore nullo.

Con il driver nouveau su una GPU Nvidia, i risultati sono stati piuttosto interessanti:

Il testo sul cubo sembra contenere i precedenti contenuti della mia finestra di terminale, che è composta sulla GPU da Compiz.

Il driver Intel GMA mostrava solo un cubo nero; era lo stesso su Android (testato con Adreno e una GPV Nvidia Tegra 3).

Naturalmente ciò non dimostra che nessuno di questi driver / sistemi è sicuro; le implementazioni OpenGL potrebbero anche inizializzare la memoria solo nel componente userspace del driver anziché nel kernel.

    
risposta data 19.07.2013 - 14:56
fonte

Leggi altre domande sui tag