Cómo mitigar el riesgo de fantasmas en el búfer X11 (error de palinopsia)

Navega tus respuestas
7

El fenómeno del "fantasma" del búfer

Es posible observar el contenido de los buffers de gráficos (antiguos y usados actualmente) en un monitor bajo ciertas circunstancias, lo que representa un riesgo de divulgación de información cuando se combina con la navegación por los hombros:

  1. Hacer crecer una ventana rápidamente en algunos administradores de ventanas de apilamiento y mosaico (siempre)
  2. Cerrar el servidor X11 (a veces)

Una parte de (1) o la pantalla completa (2) mostrará partes de las ventanas actualmente activas (posiblemente de diferentes áreas de trabajo / escritorios), o ventanas cerradas desde hace mucho tiempo.

Estos a veces se ven ligeramente o muy "dañados" según la edad y la actividad del búfer desde la destrucción de la ventana. Los búferes remanentes mostrados a veces parecen "hojas de sprites".

Este fenómeno ocurre durante una fracción de segundo en el cambio de tamaño, o ~ 1 segundo en el apagado de X11, por lo que no es práctico proporcionar capturas de pantalla. Lo siento.

La pregunta central

¿Cómo puedo mitigar o eliminar de manera viable el riesgo de revelar la información contenida en estos búferes remanentes?

Esto supone que no es práctico ocultar siempre mi monitor, lo que sería el método clásico de navegación por los hombros.

Información adicional

Intente explicar las causas

Esto solo ocurre en servidores X locales, no sobre ssh, por lo que asumo que los buffers subyacentes están en la memoria de la tarjeta gráfica.

Hipótesis basadas en la consulta de documentación xlib:

  1. El servidor X11 proporciona un búfer ampliado para pintar la ventana (ahora más grande), pero la aplicación que proporciona la ventana no se despeja ni pinta por completo en esta ventana antes de que el servidor X11 comience a mostrarla. Esto lleva a la lectura de algunos datos de basura en los buffers, que a veces resultan ser imágenes coherentes si la memoria del buffer se usó para otra ventana previamente.

  2. Después del cierre del servidor X11, quedan datos de basura en los buffers subyacentes de las ventanas antiguas. La tarjeta gráfica todavía está activa, pero la configuración del modo kernel no se ha controlado todavía, y los datos de basura se generan durante algún tiempo.

Reproducido en estas configuraciones

En el tamaño de la ventana & Cierre del servidor X11:

  • Arch Linux (más reciente), i3, xorg-server 1.18.3-1, nvidia-340xx, Nvidia GT218
  • OpenSuSE Linux 13.2 | 42.1, i3, x11-video-nvidiaG02 | G03 | G04, Nvidia G98 Quadro
  • Debian Jessie Linux, i3, xorg-server, nouveau | mesagl, gráficos integrados de inteligencia

En el cierre del servidor X11:

  • Opensuse 13.2 | 42.1, LXDE | GNOME | KDE, x11-video-nvidiaG02 | G03 | G04, Nvidia G98 Quadro
pregunta mustangflyer 19.05.2016 - 22:13
fuente

1 respuesta

5

Una respuesta parcial:

Lo que usted llama "buffer ghosting", también se conoce como error de palinopsia . El enlace proporciona una prueba de concepto , un script corto para mostrar su RAM de video con contenido de aplicaciones ya cerradas. Aparte de la RAM normal, la RAM de video de la GPU no se pone a cero por defecto cuando se asigna. Algunos conductores lo hacen, otros no; Poner a cero la memoria RAM cuesta ligeramente el rendimiento.

Puede prohibir que una aplicación tenga acceso a GPU con cookies no confiables. Ejemplo: %código% xauth -f $HOME/mycookie generate . untrusted XAUTHORITY=$HOME/mycookie glxgears no se iniciará porque no tiene acceso a la GPU. El uso de glxgears en lugar de trusted permite el acceso a la GPU, y glxgears funciona.

Se puede guardar el uso de cookies no confiables en un administrador de ventanas no compositivo como i3 o openbox. La composición de los administradores de ventanas en los escritorios respectivos con efectos 3D como Gnome o KDE puede almacenar el contenido de la ventana en la memoria de video, incluso si la aplicación en sí no lo hace. No estoy seguro de que la X pueda usar RAM de video en casos no preconcebidos aquí.

  

Esto solo ocurre en servidores X locales, no sobre ssh

Afaik, ssh siempre utiliza cookies que no son de confianza.

  

¿Cómo puedo mitigar o eliminar de manera viable el riesgo de divulgar la información contenida en estos búferes remanentes?

Nunca uses tu GPU ( suspiro ). Grita a los desarrolladores Escribe un informe de error. No vea pron en el modo de incógnito de Chrome .

La RAM de video incluso sobrevive al reinicio de un sistema a otro.

La única forma segura real puede ser deshabilitar la GPU en el nivel del kernel.

Desde un punto de vista de seguridad, el controlador debe poner a cero la memoria de video inmediatamente después de desasignar , ya que se puede acceder a la memoria de video sin usar el controlador y también persiste después de reiniciar. Al menos debe poner a cero la memoria de video cuando se asigna. Ninguno de los dos está hecho.

Algunas aplicaciones pueden tener problemas con las cookies que no son de confianza. También existe la posibilidad de deshabilitar la extensión OpenGL / GLX en el servidor X. (Tenga en cuenta que esto no tiene ningún efecto para compositores de Wayland como la sesión de Gnome 3 Wayland).

Crear un archivo: 

/etc/X11/xorg.conf.d/disable-gpu.conf

con el contenido: 

Section "Extensions"
    Option "GLX" "Disable"
EndSection

En lugar de esta configuración permanente de xorg.conf, puede ejecutar X una sola vez con GLX deshabilitado. Inicia X desde tty2 con untrusted . (Establezca startx -- -extension GLX vt2 en N con el número de tty).

    
respondido por el mviereck 07.06.2017 - 02:20
fuente

Lea otras preguntas en las etiquetas

Use OpenId Connect solo para autenticación ¿Cómo evitar que los datos del servidor de archivos sean retenidos como rehenes por el ransomware del cliente?