¿Qué tan seguro es capturar un archivo arbitrario?

A veces, cuando catpor error tengo un archivo binario, mi terminal se ve mal. Nada que un rápido resetno pueda solucionar, pero ¿no podría un atacante crear teóricamente un archivo que, cuando se muestra en un terminal, ejecutaría algún código arbitrario? A través de un exploit en el emulador de terminal o de otra manera.

El hecho de que dicha salida pueda explotarse depende del programa del terminal y de qué hace ese terminal según los códigos de escape que se envían. No conozco los programas de terminal que tienen características tan explotables, y el único problema ahora sería si hay un desbordamiento de búfer desconocido o algo así, que podría explotarse.

Con algunos hardwareterminales más antiguos esto podría ser un problema ya que programó, por ejemplo, teclas de función con este tipo de secuencias de escape, almacenando una secuencia de comandos para esa tecla en el hardware. Aún necesitaría presionar una tecla física para activar eso.

Pero siempre hay (como Hauke ​​marcó tan acertadamente como "cerebro muerto") personas dispuestas a agregar una característica de este tipo si les resuelve un problema, sin comprender la laguna que crean. En mi experiencia con el software de código abierto es que, debido a los muchos ojos que miran el código, es menos probable que esto suceda como con el código cerrado. (Recuerdo que en el programa de correo de Irix de Silicon Grahpics, a mediados de los noventa, podría incluir comandos para ejecutar en la máquina receptora, rutas reales a los ejecutables, ...)

La mayoría de los emuladores de terminal enviarán alguna respuesta, si reciben ciertas secuencias de escape (eche un vistazo a la documentación de secuencias de control xterm ). Por ejemplo, puede enviar \e[0ca un emulador similar a VT100 y devolverá los atributos del dispositivo, algo así como \e[?1;2c (Esto es probablemente lo que observó Keith). Pero estas respuestas no son cadenas arbitrarias. Aún así, tener un ejecutable nombrado en 2calgún lugar de su sistema que haga algo fatal es una mala idea.

Actualización: los riesgos son, de hecho, mayores de lo que pensaba, debido a la posibilidad de establecer el título de una ventana xterm y enviar el título utilizando secuencias de escape apropiadas ( http://www.securityfocus.com/bid/6940/ ) . A diferencia del ejemplo anterior, el título puede ser una cadena casi arbitraria.

Esto cambia el título del terminal en GNOME Terminal 3.6.1, a menos que sea anulado por algo como PS1 :

printf "\033]2;Script Kiddie was here\007"

Ahora abra una nueva ventana de Terminal de GNOME para probar la catversión:

printf "\033]2;Script Kiddie was here\007" > test.bin
cat test.bin

Sí, esto también establece el título del terminal.

Solía ​​haber un problema de seguridad con un código de escape que daba como resultado que el título se imprimiera en la línea de comando , por lo que podría crear efectivamente un archivo, que cuando cated se imprima (no estoy seguro de si podría poner una nueva línea allí) comandos arbitrarios ¡Ay!

Si bien el uso catpuede no dar lugar a la ejecución del código, los códigos de escape se procesarán para que pueda engañarse fácilmente al pensar que el script es inofensivo cuando de hecho es malicioso.

Aquí hay un comando de ejemplo que puede ejecutar que creará un script de shell "malicioso":

echo -e '#!/bin/sh\necho "...doing something bad here..."\nexit\n\033[A\033[Aecho "Hello dear reader, I am just a harmless script, safe to run me!"' > demo.sh
chmod a+x demo.sh

Cuando inspeccionas el archivo, parece bastante inofensivo:

$ cat demo.sh
#!/bin/sh
echo "Hello dear reader, I am just a harmless script, safe to run me!"

Pero si realmente lo ejecutas ...

$ ./demo.sh 
...doing something bad here...

El script funciona al incluir códigos de escape sin procesar para mover el cursor hacia arriba un par de líneas, por lo que el resto del script se escribe sobre la parte superior del código malicioso, ocultándolo.

Casi cualquier otro programa revelará el guión de lo que es. Solo los programas que no procesan el contenido del archivo (como cat, morey less -r) producirán resultados engañosos.

Tenga en cuenta que taily headtambién produce la misma salida engañosa. Usar "menos + F" es, por lo tanto, más seguro que "tail -f".

Definitivamente he experimentado la xterminserción de caracteres arbitrarios en sí mismo como si los hubiera escrito. Y en ocasiones esto aparentemente ha incluido el carácter de nueva línea, por lo que obtuve ngwerm:0riu: command not foundcomo respuesta. No veo ninguna razón por la que alguien no pueda crear un archivo que envíe comandos específicos y dañinos. Entonces sí, al menos algunas terminales son susceptibles a ataques con impacto arbitrario.

Bueno, un emulador de terminal básicamente simplemente imprime los caracteres que se le envían.

Cualquier cosa además de simplemente imprimir un personaje en la posición actual, como establecer una nueva posición, cambiar el color, cambiar el título, etc., se realiza mediante secuencias de escape.

El conjunto de secuencias de escape compatibles generalmente consta de estándares bien definidos como ANSI , que no define una forma de iniciar otros procesos. Aunque sería posible implementar tal secuencia, no conozco ningún emulador de terminal que permita intencionalmente tales cosas.

En teoría, un error como un desbordamiento del búfer podría usarse para activar una funcionalidad arbitraria. Pero esto también sería posible en prácticamente cualquier otro binario.

En general, generalmente no hay riesgo de atrapar un archivo arbitrario. Mi método habitual para analizar un archivo es hacer lo siguiente:

$ file <mystery file>
$ strings <mystery file> | less

Lo anterior me permite determinar el tipo de archivo a través del filecomando y el stringscomando me permite volcar cualquier cadena identificable de los posibles archivos binarios que no estoy seguro acerca de su linaje.

ejemplo

$ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped

$ strings /bin/ls|less
...
across
vertical
single-column
force
never
auto
if-tty
slash
%b %e  %Y
%b %e %H:%M
long-iso
main
posix-
sort_files
?pcdb-lswd
dev_ino_pop
Try `%s --help' for more information.
Usage: %s [OPTION]... [FILE]...
List information about the FILEs (the current directory by default).
Sort entries alphabetically if none of -cftuvSUX nor --sort.
Mandatory arguments to long options are mandatory for short options too.
  -a, --all                  do not ignore entries starting with .
  -A, --almost-all           do not list implied . and ..
...