¿Es WebGL un problema de seguridad?

24

¿Es WebGL un problema de seguridad potencial debido al bajo nivel de acceso que proporciona?

Por ejemplo, una página web puede intentar compilar y ejecutar cualquier fuente de sombreado que desee.

Parece que la seguridad sería especialmente un problema con los navegadores web de código abierto, ya que un atacante podría encontrar vulnerabilidades más fácilmente en la implementación.

    
pregunta 16.04.2012 - 05:16
fuente

5 respuestas

27

Sí, WebGL es un riesgo potencial para la seguridad, aunque la magnitud del riesgo es difícil de evaluar y está abierta al debate. Hay algunos problemas difíciles aquí. Los navegadores han establecido algunas defensas contra los riesgos de seguridad, pero parece haber cierto debate sobre si esas defensas resultarán adecuadas a largo plazo.

Un riesgo importante es que WebGL implica ejecutar código directamente en la tarjeta de video y exponer las API que brindan acceso directo a las API de la tarjeta de video. El navegador intenta aislar este código (hasta cierto punto), y los navegadores imponen una serie de restricciones de seguridad diseñadas para prevenir comportamientos maliciosos. Sin embargo, muchas de estas API y sus implementaciones no fueron diseñadas originalmente para ser proporcionadas a entidades que no son de confianza (solo podían ser utilizadas por aplicaciones nativas, que son de plena confianza), por lo que existe la preocupación de que su exposición a sitios web arbitrarios pueda habilitar sitios web. para atacar tu sistema.

Hubo un documento técnico de alta visibilidad (vea también < a href="http://www.khronos.org/webgl/security/"> la continuación ) que analizó la seguridad de la implementación de WebGL en los navegadores en ese momento y encontró una serie de vulnerabilidades. Encontraron algunos problemas de seguridad de la memoria en varias API de WebGL y también encontraron algunos ataques que permitirían a un sitio web leer datos de píxeles de otros sitios web (lo que podría permitir una violación de la confidencialidad). Consulte también este tercer estudio , que demostró la existencia de estas vulnerabilidades en un número de navegadores y tarjetas web (en el momento).

Los navegadores han respondido a esto con una variedad de defensas: tienen tarjetas de video en lista negra con problemas de seguridad conocidos; han intentado solucionar los problemas de seguridad de memoria conocidos; y tienen un uso restringido de WebGL según la política del mismo origen , para evitar un sitio web malintencionado desde usando WebGL para espiar el uso de otros sitios web por parte de los usuarios .

Hay un debate en curso sobre si estas defensas resultarán adecuadas a largo plazo. Microsoft ha tomado la posición de que WebGL es demasiado grande un riesgo de seguridad y las defensas existentes no son lo suficientemente robustas . Por otro lado, Mozilla toma la posición de que las defensas que han colocado serán adecuadas y que WebGL proporciona un valor importante a la web. Ars Technica tiene an Excelente resumen del tema ; y aquí hay otro informe de prensa .

P.S. Estoy totalmente en desacuerdo con su afirmación de que es un problema particular para los navegadores web de código abierto. Eso es un mito. Consulte Open Source vs Closed Source Systems , que ya cubre estos argumentos. (Consulte también Chrome vs Explorer: ¿cómo explicar con palabras sencillas que el código abierto es mejor? para una discusión más detallada) sobre este tema.)

    
respondido por el D.W. 17.04.2012 - 00:22
fuente
9

Algunos puntos clave:

  • WebGL no solo está exponiendo OpenGL a JavaScript. Todos los puntos de entrada se han restringido para eliminar las posibilidades de accesos a la memoria fuera de los límites, de modo que siempre es posible que el navegador verifique los accesos fuera de los límites (y esto está cubierto por las pruebas de conformidad). li>
  • WebGL permite ejecutar sombreadores casi arbitrarios en la GPU. Sin embargo, tenga en cuenta que los shaders no son códigos arbitrarios de propósito general. Solo pueden acceder a la memoria muy específica de manera que los navegadores verifiquen los accesos fuera de los límites. Los sombreadores son validados y traducidos por un compilador de sombreadores integrado en el navegador antes de pasar al controlador de GPU.
  • Hubo solo una falla de seguridad en una especificación de WebGL, alguna vez: la especificación de WebGL originalmente permitía el uso de imágenes de origen cruzado como texturas de WebGL, y se demostró que un ataque de tiempo podría leerlas con éxito. Esto se corrigió a mediados de 2011 y la versión actual de la especificación de WebGL, 1.0.1, es segura.
  • Puede encontrar más información sobre la seguridad de WebGL aquí: enlace
respondido por el Benoit Jacob 30.04.2012 - 14:40
fuente
3

Parece que la seguridad sería especialmente un problema con los navegadores web de código abierto.

Su señor está muy equivocado . Se ha demostrado muchas veces que los programas de código abierto son a menudo mucho más seguros que los de código cerrado, porque hay muchos más ojos que verifican el código.

También todos los navegadores ejecutan estas cosas en una caja de arena. Salir de la caja de arena será difícil, pero será tanto un problema en el código cerrado como en los navegadores de código abierto.

    
respondido por el Lucas Kauffman 16.04.2012 - 07:55
fuente
1

Comparemos WebGL con javascript.

La diferencia crítica entre (código de sombreado ejecutado a través de WebGL y javascript) es que el código de sombreado se ejecuta en la tarjeta de GPU, mientras que javascript se ejecuta en la CPU.

El hecho de que el código sea interpretado o compilado tiene poca importancia; el potencial resultante de vulnerabilidades sigue ahí.

Por lo tanto, javascript tiene más capacidad de abuso, ya que una vez que una secuencia de comandos maliciosa sale de la cárcel del navegador, básicamente tiene acceso a su PC. Un script de sombreado WebGL no autorizado podría obtener, uh, acceso a su GPU.

Hay factores que complican esta simple vista; javascript ha existido por un tiempo, por lo que ha recibido más escrutinio y ha tenido más agujeros cerrados. JavaScript es mucho más complicado. Javascript como idioma es mucho más complicado. etc. etc.

    
respondido por el Michael Slade 30.04.2012 - 16:24
fuente
0

WebGL permite el acceso al canal de GL a sus núcleos de GPU. Algunos fabricantes integran GPU directamente en el chip de la CPU. Esto permite que la GPU comparta la memoria interna de la CPU, en lugar de tener su propia memoria, como es el caso con conjuntos de chips de gráficos externos. Este es un riesgo potencial para la seguridad de la información.

Los procesadores paralelos que consumen mucha energía, como las GPU, también son ideales para aplicaciones de criptografía.

Hay muchos ejemplos de bitminers basados en webgl en botnets. Si bien no son una amenaza para la seguridad de la información (a la inversa, los bitminers son la base para la seguridad de la información de la cadena de bloques), estas botnets roban una asombrosa cantidad de energía de las vastas redes de dispositivos involuntarios en los que se ejecutan.

Esto significa que Bitcoin tiene una huella de carbono creciente pero en gran parte oculta, lo que es una amenaza potencial para la seguridad ambiental.

Si alguna vez observa que algunos sitios web ralentizan su pantalla sin aumentar la carga de la CPU, es muy probable que estén ejecutando el código webgl en su GPU. También una causa probable de los misteriosos drenajes de energía de dispositivos móviles.

Las aplicaciones móviles (como los navegadores web) pueden ejecutar el código de GPU permanentemente en segundo plano, y pueden requerir un reinicio del dispositivo para detenerlos.

    
respondido por el Dominic Cerisano 03.06.2017 - 23:59
fuente

Lea otras preguntas en las etiquetas