Pregunta:
Al leer los detalles de CVE-2009-4487 (que trata sobre el peligro de las secuencias de escape en los archivos de registro) , estoy un poco sorprendido.
Para citar CVE-2009-4487 :
nginx 0.7.64 escribe datos en un archivo de registro sin desinfectar los caracteres no imprimibles, lo que podría permitir a atacantes remotos modificar el título de una ventana, o posiblemente ejecutar comandos arbitrarios o sobrescribir archivos, a través de una solicitud HTTP que contiene una secuencia de escape para un emulador de terminal.
Claramente, esto no se trata realmente de un agujero de seguridad en nginx, sino en los emuladores de terminal.
Claro, tal vez la cat de un archivo de registro en la terminal ocurre solo por accidente, pero la grep de un archivo de registro es bastante común. less quizás desinfecte las secuencias de escape, pero quién sabe qué comandos de shell no cambian las secuencias de escape …
Tiendo a estar de acuerdo con la respuesta de Varnish :
La sabiduría de los escapes de respuesta terminal en general se ha cuestionado a intervalos regulares, pero ninguno de los principales programas de emulación de terminal ha considerado adecuado descartar estas secuencias, probablemente en un intento equivocado de compatibilidad con la tecnología que ya no se usa en los años 70. [..] En lugar de culpar a todos y cada uno de los programas que escriben archivos de registro, sería mucho más productivo, desde el punto de vista de la seguridad, lograr que los programas de emulación de terminal dejen de hacer cosas estúpidas y, por lo tanto, solucionar este y otros problemas de seguridad una vez. y para todos.
De ahí mis preguntas:
¿Cómo puedo proteger mi xterm, de modo que ya no sea posible ejecutar comandos o sobrescribir archivos a través de secuencias de escape?
¿Qué emuladores de terminal para X están protegidos contra este ataque?
Respuesta:
Los terminales VT100 (que todos los emuladores de terminal modernos emulan hasta cierto punto) admitían una serie de comandos problemáticos, pero los emuladores o distribuciones modernos deshabilitan los más problemáticos y menos útiles. Aquí hay una lista no exhaustiva de secuencias de escape potencialmente riesgosas (sin incluir las que simplemente hacen que la pantalla sea ilegible de alguna manera):
- Los comandos de archivo de registro arbitrarios en rxvt y Eterm informados por HD Moore . De hecho, estos son errores importantes, afortunadamente arreglados durante mucho tiempo.
- El comando de respuesta, también conocido como Devolver estado del terminal, invocado por
ENQ(Ctrl+E). Esto inserta texto en el terminal como si el usuario lo hubiera escrito. Sin embargo, este texto no está bajo el control del atacante: es el propio nombre de la terminal, típicamente algo así comoxtermoscreen. En mi sistema (Debian squeeze), xterm devuelve la cadena vacía de forma predeterminada (esto está controlado por el recursoanswerbackString). - Los comandos Enviar atributos de dispositivo,
ESC [ camigos. El terminal responde conESC [ … c(donde…puede contener dígitos y signos de puntuación ASCII). Esta es una forma de consultar algunas capacidades del terminal, en su mayoría obsoletas pero quizás utilizadas por aplicaciones antiguas. Nuevamente, la respuesta del terminal es indistinguible de la entrada del usuario, pero no está bajo el control del atacante. La secuencia de control puede parecer una tecla de función, pero solo si el usuario tiene una configuración inusual (ninguna de las configuraciones habituales que he encontrado tiene una secuencia de escape de tecla de función válida que sea un prefijo de la respuesta del terminal). - Las diversas funciones de control del dispositivo (DCS se escapa, comenzando con
ESC P).- No sé qué daño se puede hacer a través de
DECUDK(establecer claves definidas por el usuario) en un emulador de terminal típico. -
DECRQSS(Cadena de estado de solicitud) es otro comando al que el terminal responde con una secuencia de escape, esta vez comenzando con\eP; esto puede ser problemático ya que\ePes una tecla válida ( Alt + Shift + P ). - Xterm tiene dos características experimentales más:
ESC P + p …yESC P + q …, para obtener y establecer cadenas termcap. De la descripción, esto podría usarse al menos para modificar el efecto de las teclas de función.
- No sé qué daño se puede hacer a través de
- Varios comandos de informe de estado:
ESC [ … n(Informe de estado del dispositivo). El terminal responde con una secuencia de escape. La mayoría de estas secuencias de escape no se corresponden con las secuencias de escape de teclas de función. Uno parece problemático: el informe aESC [ 6 nes de la formaESC [ x ; y Rdondexyyson las secuencias de dígitos, y esto podría parecerse a F3 con algunos modificadores. - Comandos de manipulación de ventanas
ESC [ … t.- Algunos de estos permiten cambiar el tamaño de la ventana de xterm, iconificarlos, etc., lo cual es perturbador.
- Algunos de estos hacen que el terminal responda con una secuencia de escape. La mayoría de estas secuencias de escape parecen de bajo riesgo, sin embargo, hay dos comandos peligrosos: las respuestas a
ESC [ 2 0 tESC [ 2 1 tincluyen la etiqueta del icono y el título de la ventana de terminal respectivamente, y el atacante puede elegirlos. - Al menos en Debian squeeze, xterm ignora estos comandos por defecto; se pueden habilitar configurando el recurso
allowWindowOps, o de forma selectiva a través del recursodisallowedWindowOps. Gnome-terminal en Ubuntu 10.04 implementa incluso los answerbacks del título de forma predeterminada. No he comprobado otros terminales o versiones.
- Comandos para establecer el título del terminal o el nombre del icono. En xterm y la mayoría de los otros terminales X, son
ESC ] digit ; title ESC \. En Pantalla, la secuencia de escape esESC k title ESC \. Encuentro la preocupación por estos comandos sobrevalorada. Si bien permiten cierta cantidad de travesuras, cualquier página web tiene el mismo problema. Actuar en una ventana basándose únicamente en su título y no en su clase es similar a abrir un archivo cuyo nombre le dio una parte que no es de confianza, o no citar una expansión variable en un script de shell, o acariciar a un perro rabioso en la nariz. – no te quejes si te muerden.
Encuentro falsa la respuesta de Varnish. Se siente como si estuviera tratando de echar la culpa, o en modo nazi de seguridad (cualquier problema de seguridad, genuino o no, justifica la exclusión de una función).
La sabiduría de los escapes de respuesta terminal en general se ha cuestionado a intervalos regulares, pero ninguno de los principales programas de emulación de terminal ha considerado adecuado descartar estas secuencias, probablemente en un intento equivocado de compatibilidad con la tecnología que ya no se usa en los años 70. (…)
En lugar de culpar a todos y cada uno de los programas que escriben archivos de registro, sería mucho más productivo, desde el punto de vista de la seguridad, lograr que los programas de emulación de terminal dejen de hacer cosas estúpidas y, por lo tanto, solucionar este y otros problemas de seguridad de una vez por todas.
Muchas de las respuestas son funciones útiles: una aplicación necesita saber cosas como la posición del cursor y el tamaño de la ventana. Establecer el título de la ventana también es muy útil. Sería posible confiar completamente en las llamadas ioctl para estos, sin embargo, esto habría requerido código y utilidades adicionales para realizar estas llamadas ioctl y realizar transacciones en texto estilo Unix pasando descriptores de archivo. Cambiar estas interfaces ahora sería mucho trabajo, con pocos beneficios.
Se supone que los archivos de texto no deben contener caracteres que no se impriman, como caracteres de control. Por lo general, se espera que los archivos de registro sean archivos de texto. Los archivos de registro no deben contener caracteres de control.
Si usted está preocupado de que un archivo puede contener secuencias de escape, abrirlo en un editor, o verlo con less sin la -r , o -R opción, o visualizarla a través cat -v .