¿El cat-ing de un archivo puede ser un riesgo potencial para la seguridad?

Sí , es un riesgo potencial, consulte CVE-2003-0063, o CVE-2008-2383 o CVE-2010-2713, o CVE-2012-3515 o OSVDB 3881, o CVE-2003-0020 o cualquiera de los similares enumerados aquí ... Algunos más en los comentarios a continuación también.

Actualizar no es solo un potencial riesgo, es un riesgo real .rxvt-unicode (versiones 2.7—9.19, parcheado en 9.20) permite el acceso de lectura/escritura a las propiedades de la ventana X, esto puede habilitar la ejecución asistida por el usuario de comandos arbitrarios, este problema se ha asignado CVE-2014-3121, más detalles aquí https ://bugzilla.redhat.com/show_bug.cgi?id=1093287 .

Más recientemente (Octubre de 2019) iTerm2 Se encontró que las versiones hasta v3.3.5 tenían la misma clase de problema:la visualización de contenido malicioso puede habilitar el tmux integrado y permitir la ejecución de comandos, consulte CVE-2019-9535.

Este tema también tiene una buena cobertura aquí:https://unix.stackexchange.com/questions/73713/how-safe-is-it-to-cat-an-arbitrary-file y un análisis exhaustivo del problema subyacente de Gilles aquí:https://unix.stackexchange.com/questions/15101/how-to-avoid-escape-sequence-attacks-in-terminals.

Explicación

Lo que está observando es un efecto secundario de cómo se comportan ciertas secuencias de escape:algunas de ellas rellenan caracteres (generalmente también contienen secuencias de escape) directamente en el búfer de entrada del terminal . Todo en nombre de la compatibilidad con versiones anteriores, por supuesto. El estándar xterm los escapes que se describen usando el término "Reportar " hacen esto. Este comportamiento permite que los programas consulten/establezcan las propiedades del terminal (u otras) "en banda" en lugar de mediante ioctls o alguna otra API.

Como si eso no fuera suficientemente malo, algunas de estas secuencias pueden contener una nueva línea , lo que significa que cualquier cosa que esté leyendo desde la terminal (tu shell) verá lo que parece ser un comando de usuario completo.

Aquí hay una buena manera de usar esto, con read de bash para imprimir un escape (como mensaje) y luego leer y dividir inmediatamente la respuesta en variables:

IFS=';' read -sdt -p $'\e[18t' csi8 rows cols
echo rows=$rows cols=$cols

Estas secuencias pueden variar según el terminal, pero para rxvt y derivada, la consulta de gráficos escape incluye una nueva línea (ejemplo usando bash y $'' cadenas, consulte doc/rxvtRef.txt en la fuente)` :

$ echo $'\eGQ'
$ 0
bash: 0: command not found

Este escape envía \033G0\n en el búfer de entrada del terminal (o el dígito 1 en lugar de 0 si tiene un rxvt compatible con gráficos ).

Entonces, combina este escape con otras secuencias que se comportan de manera similar:

echo $'\x05' $'\e[>c' $'\e[6n' $'\e[x' $'\eGQ'

para mí esto provoca 11 intentos de ejecutar varios comandos:1 , 2c82 , 20710 (mi rxvt cadena de versión), 0c5 , 3R (5 y 3 fueron las coordenadas del cursor), 112 y 0x0 .

¿Explotable?

Con rxvt y los emuladores de terminal más recientes, "solo" debería poder crear un conjunto limitado de secuencias en su mayoría numéricas. En los antiguos emuladores de terminales era posible (algunos CVE enumerados anteriormente) acceder al portapapeles, el ícono de la ventana y el texto de la barra de título para construir más cadenas maliciosas para la invocación (una pequeña excepción actual es si configura el answerbackString cadena de recursos X, pero no se puede configurar directamente con este método). La falla entonces es permitir la lectura arbitraria y acceso de escritura a algo que pasa por estado o almacenamiento dentro de secuencias de escape que introducen datos en el búfer de entrada.

rxvt requiere cambios en el tiempo de compilación para activarse, pero urxvt amablemente tiene un -insecure opción de línea de comandos que habilita algunas de las funciones más interesantes:

$ echo $'\e]2;;uptime;\x07' $'\e[21;;t' $'\eGQ' 
bash: l: command not found
17:59:41 up 1448 days,  4:13, 16 users,  load average: 0.49, 0.52, 0.48
bash: 0: command not found

Las tres secuencias son:

1. \e]2;...\x07 establecer el título de la ventana;
2. \e[21;;t título de la ventana de consulta, lugar en el búfer de entrada;
3. \eGQ capacidad de consulta de gráficos, que agrega \n al búfer de entrada.

Nuevamente, dependiendo de la terminal, se puede acceder a otras funciones como el tamaño de la fuente, los colores, el tamaño de la terminal, el conjunto de caracteres, los búferes de pantalla alternativos y más a través de los escapes. La modificación no intencionada de estos es al menos un inconveniente, si no un problema de seguridad total. Versiones actuales de xterm restrinja funciones potencialmente problemáticas a través de los recursos "Permitir*".

CVE-2014-3121

Antes de v9.20, urxvt tampoco protegió el acceso de lectura y escritura a las propiedades X (principalmente utilizado por los administradores de ventanas). Escribir el acceso de lectura (o más precisamente, el acceso a secuencias que hacen eco de cadenas potencialmente arbitrarias) ahora requiere el -insecure opción.

$ echo $'\e]3;xyzzy=uptime;date +%s;\x07'
$ xprop -id $WINDOWID xyzzy
xyzzy(UTF8_STRING) = 0x75, 0x70, 0x74, 0x69, 0x6d, 0x65, 0x3b, 0x64, 0x61, 0x74, \
0x65, 0x20, 0x2b, 0x25, 0x73, 0x3b

Esto se puede usar de forma trivial para rellenar cadenas arbitrarias en el búfer de entrada del terminal. Cuando se invoca la secuencia de escape para consultar una propiedad (junto con el útil \eGQ que añade una nueva línea):

 $ echo $'\e]3;?xyzzy\x07' $'\eGQ'
 $ 3;uptime;date +%s;0
 bash: 3: command not found
 17:23:56 up 1474 days,  6:47, 14 users,  load average: 1.02, 1.20, 1.17
 1400603036
 bash: 0: command not found

Múltiples comandos, preservando los espacios en blanco y los metacaracteres de shell. Esto se puede explotar de varias maneras, comenzando con un binario no confiable, por supuesto, más ideas en HD. Breve artículo de Moore (2003).

Seguimiento

Para la secuencia de escape sobre la que pregunta:1;112;112;1;0x1;2 Esto es:Solicitar parámetros de terminal (DECREQTPARM) y Enviar atributos de dispositivo :

$ echo $'\e[x' $'\e[0c'
;1;1;112;112;1;0x1;2c

El segundo (\e[0c ) es lo mismo que ^E (usando rxvt ). También hay algunas secuencias de escape. la secuencia completa escrita para cada uno es, respectivamente:

\e[1;1;1;112;112;1;0x
\e[?1;2c

Definitivamente sí.

Nueva adición 2020-01-25:

Desde que cambié de LATIN-1 codificación a UTF-8 como codificación predeterminada en la mayoría de mis sistemas, he encontrado algunas características interesantes alrededor de esto (ahora hay dos longitudes para una cuerda)...

Por ejemplo, como me gusta jugar con bash , he preguntado por qué la localización de bash no funcionará con cadenas de varias líneas. Esta característica bash presenta un error, donde la solución consiste en usar eval . Si esto no es falla de seguridad , esto podría convertirse o producir uno...

En todas las evoluciones de casi cualquier cosa (lenguajes, bibliotecas, herramientas, protocolos, aplicaciones, hardware, instaladores, consolas, etc...) aparecen nuevas características, con errores potencialmente nuevos...

Afortunadamente, son tan pocos como se corrigen rápidamente (casi un día de revelar), ¡pero lo son!

Así que definitivamente sí, ¡cuídate!

Uso correcto de cat comando.

Como parece estar usando un moderno emulador de terminal , algunas secuencias de escape podría usarse para modificar Búfer de teclado .

Podría haber comandos de shell adecuados inyectados.

Podrías usar el argumento -e de cat para un funcionamiento seguro, consulte man cat .

  -e     equivalent to -vE

  -E, --show-ends
         display $ at end of each line

  -v, --show-nonprinting
         use ^ and M- notation, except for LFD and TAB

Entonces

$ cat -e suspectfile.raw
$ cat -e suspectfile.raw | less

o bajo bash:

$ less < <(cat -e suspectfile.raw)

o incluso

$ which less cat
/usr/bin/less
/bin/cat
$ rawless() { /usr/bin/less < <(/bin/cat -e "[email protected]");}

Observaciones

Cuando lees command not found , esto implica que algo fue efectivamente inyectado.

La inyección principal función que no se elimina la secuencia identifíquese , utilizado en muchas encapsulaciones VT-100.

Esta secuencia es Escape Z que inyectará la cadena 1;2c en el búfer de tu teclado, lo que significa VT-100 (en la convención AVO).

Hablando de cat , podrías probar:

$ cat <<< $'\033Z'

U otra secuencia ANSI:CSI c (Atributos del dispositivo ):

$ cat <<< $'\033[c'

imprimirá una línea vacía, pero en la siguiente línea que se le solicite, verá 1;2c (o tal vez con otros números, dependiendo del terminal utilizado) como si usted los golpeó:

$ 65;1;9c█

... pero con -e cambiar:

$ cat -e <<< $'\033Z'
^[Z$
$ cat -e <<< $'\033[c'
^[[c$

Donde -e => -vE , -v transformar \033 en ^[ y -E pon un $ firme al final de la línea (y no se colocará nada en la siguiente línea, usted búfer de teclado no se ve afectado).

Puede encontrar muchas cosas divertidas en la Guía del usuario de VT100 (como:cat <<< $'\033#8';)

(Eran terminales modernos ! En algún pasado... )

Intentando usar bash

Hay un pequeño comando bash para vaciar el búfer del teclado y obtener su contenido:

$ cat <<<$'\033[c';buf='';while read -t .1 -n 1 chr;do
        buf+="$chr"
  done;printf "\n>|%q|<\n" $buf

^[[?65;1;9c
>|$'\E[?65;1;9c'|<

Y una pequeña función para probar cualquier cadena:

$ trySeq() {
    printf -v out "$1"
    echo -n "$out"
    buf=""
    while read -t.1 -n1 char
      do buf+="$char"
    done
    [ "$buf" ] && printf "\r|%q|->|%q|<\e[K\n" "$out" "$buf"
}

Entonces podría probar:

$ for seq in $'\e['{c,{1..26}{n,t,x}};do
      trySeq "$seq";done
|$'\E[c'|->|$'\E[?65;1;9c'|<
|$'\E[1x'|->|$'\E[3;1;1;120;120;1;0x'|<
|$'\E[5n'|->|$'\E[0n'|<
...

(Tal vez con alguna inofensiva efectos en tu consola;)

Pequeña muestra práctica

Imagínate, alguno podría poner algo así en tu entorno:

$ source <(printf '%dc() {
     printf "You\\047ve been hitted\\041\\n"
   };\n' {0..100};printf 'alias %s=1c\n' {0..100};)

Entonces, si

$ cat <<<$'\e[c'

$ 65;1;9c█

El cursor permanecerá al final de la línea del símbolo del sistema.

A partir de ahí, si presiona mecánicamente Return en lugar de Ctrl + c , leerás algo como:

$ 65;1;9c
You've been hitted!
You've been hitted!
You've been hitted!
$ █

¿Y ahora?

A partir de ahí, por desgracia, no hay estándar .

Cada terminal virtual la implementación podría admitir el estándar ANSI completo y/o DEC completo...

Pero como hay algunos problemas de seguridad, muchos no...

Podrías observar algún comportamiento usando un terminal que no observarías usando otro...

xterm, consola linux, gnome-terminal, konsole, fbterm, Terminal (Mac OS)... ¡la lista de emuladores de terminal no es tan corta!

Y cada uno de ellos tiene sus propios errores y limitaciones en comparación con los estándares DEC y ANSI.

En la práctica, puede encontrar alguna consola virtual que podría tener más características que otro y donde inyección de teclado podría romper su seguridad.

Es una de las razones por las que prefiero usar siempre el mismo (antiguo) xterm en lugar de otras herramientas más destacadas.

Los terminales de vidrio "reales" tenían una secuencia de escape para imprimir la pantalla en una impresora. Hicieron esto ejecutando un comando y canalizando el contenido de la pantalla actual al stdin del comando de impresión.

El comando podría configurarse mediante otra secuencia de escape.

La forma clásica de explotar esto era crear archivos con nombres que incrustaran la secuencia de escape para configurar el comando de la impresora y cambiarlo a algún script de su elección y luego tener un segundo archivo con la secuencia de escape de impresión.

Cuando alguien ejecutó ls en ese directorio terminarían ejecutando su código. Lo cual estaría bien si fueran los root usuario!

En teoría, los emuladores de terminales modernos ya no deberían hacer ese tipo de cosas.

Terminal.app parece estar basado en el nsterm NextStep, por lo que puede contener todo tipo de rarezas.

Tal vez intente reducir qué bytes exactos están produciendo el command not found mensajes?

Parece que hay secuencias de escape para subir y bajar la terminal:

http://the.taoofmac.com/space/apps/Terminal

más información aquí:

http://invisible-island.net/ncurses/terminfo.src.html#toc-_Apple__Terminal_app

Si desea enviar contenido a la entrada estándar de un programa,

program -para meters < /path/file.ext