¿Es OpenGL un problema de seguridad?

16

Hoy en día, casi todos los sistemas operativos y dispositivos móviles y de escritorio admiten alguna versión de OpenGL. Me pregunto sobre las implicaciones de seguridad de eso:

  • En muchos casos, la GPU tiene acceso completo y sin restricciones a la memoria principal (para dispositivos gráficos integrados) o al menos a la RAM de video, donde también se puede almacenar información confidencial (piense en administradores de ventanas de composición o navegadores web acelerados por hardware) .
  • En algunas implementaciones, los clientes OpenGL se comunican con la GPU escribiendo directamente datos y comandos en la memoria compartida.
  • Solo las GPU recientes parecen admitir la virtualización de la memoria, e incluso entonces, solo algunas implementaciones de controladores lo están utilizando actualmente.
  • WebGL requiere que los objetos de búfer recién asignados se inicialicen con cero; Sospecho que esto significa que esto no es necesario en OpenGL estándar. ¿Eso significa que teóricamente es posible asignar un búfer en la memoria de video y leer datos potencialmente sensibles a la seguridad?

Entonces, ¿quién o qué me impide escribir un programa de sombreado que lee datos en el video o incluso la memoria principal que no me pertenece?

He encontrado una presentación sobre el estado actual de las cosas en el sistema de gráficos de Linux que menciona que Los comandos a la GPU son verificados por el núcleo, o la memoria virtual se utiliza en la GPU para separar a los usuarios.

¿Eso también es cierto para otros sistemas operativos, especialmente los móviles, como Android, donde las aplicaciones individuales están fuertemente protegidas, pero tienen acceso OpenGL casi ilimitado? Tegra 2 incluso se menciona específicamente en esa presentación para permitir el acceso de memoria potencialmente ilimitado a los usuarios del controlador.

    
pregunta lxgr 09.05.2013 - 15:58
fuente

2 respuestas

3

Para una seguridad adecuada, las tarjetas gráficas deben tratarse como cualquier otro tipo de hardware que tenga acceso a RAM: deben estar bajo el paraguas de MMU y el programador controlado por el kernel, por lo que la ejecución simultánea de tareas no puede impactar entre sí, y puede interactuar solo a través de canales de comunicación administrados cuidadosamente por el kernel.

Como puede observar, tal aislamiento y uso compartido para los controladores de gráficos en 3D es solo una característica reciente. Durante la mayor parte de las dos décadas anteriores, los gráficos 3D acelerados han sido un camino abierto a las vulnerabilidades ... que resultó ser muy rara vez explotado, por las siguientes razones:

  • En la mayoría de los sistemas (Windows, Linux ...), el acceso a la tarjeta 3D está autorizado solo para los usuarios que se sientan frente a la máquina, sobre la base de que una animación 3D suave simplemente no la corta La red de todos modos. Las personas malvadas que tienen acceso físico a la máquina tienen vías de entrada al sistema mucho más eficientes que las que tienen que lidiar con la GPU.

  • Tratar con los detalles de bajo nivel de GPU es un trabajo arduo, especialmente porque muchos de ellos no están documentados (por lo que los controladores propietarios todavía se usan en Linux). Los atacantes también son seres humanos, por lo tanto, inherentemente perezosos.

Las plataformas de sandboxing como los teléfonos inteligentes pueden cambiar eso, ya que alojan aplicaciones que pueden acceder al hardware 3D y ser hostiles entre sí. Pero ¿por qué les importaría? Es mucho más sencillo solicitar derechos de acceso extensos después de la instalación (el usuario simplemente responde que sí a todos).

    
respondido por el Thomas Pornin 10.05.2013 - 04:43
fuente
8

He realizado algunos experimentos en Linux y varias GPU y controladores. Tomé un tutorial básico de OpenGL para la asignación de texturas y reemplacé el puntero a los datos de textura en la llamada a glTexImage2D con un puntero nulo.

Con el controlador nouveau en una GPU Nvidia, los resultados fueron bastante interesantes:

El texto en el cubo parece contener el contenido anterior de mi ventana de terminal, que está compuesta en la GPU por Compiz.

El controlador Intel GMA mostró solo un cubo negro; fue lo mismo en Android (probado con un Adreno y un Nvidia Tegra 3 GPU).

Por supuesto, eso no prueba que ninguno de esos controladores / sistemas sea seguro; Las implementaciones de OpenGL podrían también inicializar la memoria solo en el componente del espacio de usuario del controlador en lugar de en el núcleo.

    
respondido por el lxgr 19.07.2013 - 14:56
fuente

Lea otras preguntas en las etiquetas