☰

Explicación del comando para comprobar Shellshock.

tag-icon • tag-icon bash shellshock
Explicación del comando para comprobar Shellshock.

Aquí está el comando que he usado para verificar mi shell bash en busca del error Shellshock:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

¿Alguien puede explicar el comando en detalle?

Respuesta1

Esta respuesta es una derivada de unaartículo original en la Revista Fedorapor Matthew Miller, con licencia bajo laCreative Commons Atribución-Compartir Igual 4.0licencia.

Dejame explicar:

env x='() { :;}; echo OOPS' bash -c :

Esto imprimirá "OOPS" en un sistema vulnerable, pero saldrá silenciosamente si bash ha sido parcheado.

env x='() { :;}; echo OOPS' bash -c "echo this is a test"

Esto imprimirá "OOPS" en un sistema vulnerable, pero se imprimirá “this is a test”si bash ha sido parcheado.

Y probablemente hayas oído que tiene algo que ver con las variables de entorno. Pero, ¿por qué se ejecuta el código de las variables de entorno? Bueno, no se supone que sea así, pero, debido a una característica que me siento tentado a llamar demasiado inteligente para su propio bien, hay margen para un defecto. Bash es lo que usted ve como un indicador de terminal, pero también es un lenguaje de programación y tiene la capacidad de definir funciones. Lo haces así:

$ Ubuntu()  { echo "Ubuntu is awesome."; }

y luego tienes un nuevo comando. Tenga en cuenta que echoaquí aún no se ha ejecutado; simplemente se guarda como lo que sucederá cuando ejecutemos nuestro nuevo comando. ¡Esto será importante en un minuto!

$ Ubuntu
 Ubuntu is awesome.

¡Útil! Pero digamos que, por alguna razón, necesitamos ejecutar una nueva instancia de bash, como un subproceso, y queremos ejecutar mi nuevo e increíble comando bajo eso. La declaración bash -c somecommandhace exactamente esto: ejecuta el comando dado en un nuevo shell:

$ bash -c Ubuntu
  bash: Ubuntu: command not found

Oh. Triste. El niño no heredó la definición de función. Pero es inherente al entorno: una colección de pares clave-valor que se han exportado desde el shell. (Este es un concepto completamente diferente; si no está familiarizado con esto, créame por ahora). Y resulta que bash también puede exportar funciones. Entonces:

$ export -f Ubuntu
$ bash -c Ubuntu
  Ubuntu is awesome.

Lo cual está muy bien, salvo que el mecanismo mediante el cual se logra esto esalgo dudoso. Básicamente, dado que no existe la magia de Linux/Unix para realizar funciones en variables de entorno, la función de exportación en realidad simplemente crea una variable de entorno normal que contiene la definición de la función. Luego, cuando el segundo shell lee el entorno "entrante" y encuentra una variable con contenidos que parecen una función, la evalúa.

En teoría, esto esperfectamente seguro, porque, recuerde, definir una función en realidad noejecutalo. Excepto que, y es por eso que estamos aquí, hubo un error en el código donde la evaluación no se detuvo cuando se alcanzó el final de la definición de la función. Simplemente continúa.

Eso nunca sucedería cuando la función almacenada en una variable de entorno se crea legítimamente, con export -f. Pero, ¿por qué ser legítimo? Un atacante puede simplemente inventar cualquier variable de entorno antigua, y si parece una función, ¡los nuevos shells bash pensarán que lo es!

Entonces, en nuestro primer ejemplo:

env x='() { :;}; echo OOPS' bash -c "echo this is a test"

El envcomando ejecuta un comando con un conjunto de variables determinado. En este caso, estamos configurando xalgo que parece una función. La función es solo una :, que en realidad es un comando simple que se define como no hacer nada. Pero luego, después de semi-colonque señala el final de la definición de la función, hay un echocomando. Se supone que eso no debería estar ahí, pero nada nos impide hacerlo.

Luego, el comando dado para ejecutar con este nuevo entorno es un nuevo shell bash, nuevamente con un comando " echo this is a test" o " no hacer nada :", después del cual saldrá, de manera completamente inofensiva.

Pero... ¡ups! Cuando ese nuevo shell se inicia y lee el entorno, llega a la xvariable y, como parece una función, la evalúa. La definición de la función se carga de forma inofensiva y luego también se activa nuestra carga útil maliciosa. Entonces, si ejecuta lo anterior en un sistema vulnerable, recibirá “OOPS”una copia impresa. O bien, un atacante podría hacer cosas mucho peores que simplemente imprimir cosas.

Respuesta2

Enversión sin parches debashalmacena definiciones de funciones exportadas como variables de entorno.

Almacenar una función xcomo,

$ x() { bar; }
$ export -f x

Y verifique su definición como,

$ env | grep -A1 x
x=() {  bar
}

Entonces uno podría explotar esto definiendo sus propias variables de entorno e interpretándolas como definiciones de funciones. Por ejemplo, env x='() { :;}'sería tratado como

x() { :;
}

¿Qué hace el comando para comprobar Shellshock?

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

De man env,

  1. env- ejecutar un programa en un entorno modificado.

  2. :no hacer nada más que salir con estado de salida 0. vermás

  3. Cuando se lanza una nueva instancia de bash sin parches como bash -c "echo this is a test", la variable ambiental diseñada se trata como una función y se carga. En consecuencia, se obtiene el resultado.

    vulnerable
    esto es una prueba

Nota:El eco fuera de la definición de la función se ejecutó inesperadamente durante el inicio de bash. La definición de la función es solo un paso para que se realice la evaluación y el exploit, la definición de la función en sí y la variable de entorno utilizada son arbitrarias. El shell mira las variables de entorno, ve x, que parece cumplir con las restricciones que conoce sobre cómo se ve una definición de función, y evalúa la línea, ejecutando también involuntariamente el eco (que podría ser cualquier comando, malicioso o no). . Ver tambiéneste

información relacionada