Bypass de la lista blanca del entorno Shellshock más sudo / su - ¿gran problema?

Navega tus respuestas
1

La pregunta es: ¿Qué tan grande es este problema? Me parece bastante grande.

Con el error de shellshock es posible omitir la lista blanca de variables de entorno conocidas e inofensivas en sudo, así como otras rutas para la ejecución de código como usuarios con altos privilegios. Por ejemplo, las variables MAIL y DISPLAY se propagan de forma predeterminada por sudo en muchas configuraciones (la última vez que lo verifiqué, no creo que la última versión de Debian lo haga).

En presencia de Shellshock, si un usuario sin privilegios, un usuario con privilegios parciales o un malware con ejecución de código sin privilegios puede suministrar cualquier variable de entorno propagada a un shell que se ejecute como root, puede ejecutar código arbitrario como root.

  • El usuario con sudo de derechos limitado es malicioso
  • El usuario configura una variable de entorno como MAIL a shellshock exploit code
  • Cualquier llamada a popen , system o bash por cualquier comando sudo 'd por dicho usuario ahora dará como resultado la ejecución de código arbitrario como root.
    • El resultado de
  • es que los derechos de sudo se convierten en acceso raíz al sistema. no importa qué tan restringido esté su acceso

O:

  • El usuario obtiene acceso al terminal de usuario desatendido con algunos derechos de sudo, o
  • Malware obtiene la ejecución de código como un usuario sin privilegios que tiene algunos derechos de sudo
  • La variable de entorno propagada de Malware / User establece como MAIL a shellshock exploit code
  • Cualquier llamada a popen , system o bash por cualquier comando sudo 'd por dicho usuario ahora dará como resultado la ejecución del código como raíz.
  • No requiere conocimiento de la contraseña: la contraseña puede ser ingresada posteriormente por el usuario víctima después de que el acceso haya terminado.
pregunta Ben 30.09.2014 - 16:20
fuente

2 respuestas

3

Sudo bloquea las variables de entorno que podrían ser definiciones de funciones de bash ( 2004-11-11 env.c: elimina las funciones de bash exportadas de el entorno ), incluso si el nombre de la variable está en la lista blanca. Es por eso que sudo no está incluido en la lista de vectores de ataque comunes para Shellshock.

Un script de bash invocado por su a una cuenta restringida puede ser un vector de ataque. Pero hay otros problemas con un script de shell invocado a través de su . su no elimina las variables de entorno como IFS o PATH (bash no importa IFS del entorno, pero algunas otras shells lo hacen) - o BASH_ENV , que es el nombre de un archivo donde bash lee los comandos cuando se inicia. Un script de shell invocado a través de su a una cuenta restringida necesitaría un contenedor intermedio. Este envoltorio debe tener cuidado con las variables y los valores que deja pasar.

    
respondido por el Gilles 30.09.2014 - 17:48
fuente
0

@Gilles tiene razón. Creo que los resultados de esta prueba podrían ser interesantes:

Hice una prueba con un script muy poco convincente: 

$ cat ./sudoset.bash 
#!/bin/bash-shellshock
set

Para confirmar, sin sudo: 

$ export MAIL="() { :;} ; echo busted"; ./sudoset.bash | head -3
  busted
  busted
  BASH=/bin/bash-shellshock

(no estoy seguro de por qué aparece "reventado" dos veces)

Con sudo: 

$ export MAIL="() { :;} ; echo busted"; sudo ./sudoset.bash | head -3
BASH=/bin/bash-shellshock
BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()

Pero la variable de CORREO está en la lista blanca como usted describe: 

$ export MAIL="simpletest"; sudo ./sudoset.bash | grep MAIL
MAIL=simpletest

Tan pronto como contiene una definición de función, sudo parece eliminarlo: 

$ export MAIL="() { :;} ; echo busted"; sudo ./sudoset.bash | grep MAIL
MAIL=/var/mail/root
    
respondido por el mgjk 30.09.2014 - 18:32
fuente

Lea otras preguntas en las etiquetas

Cómo proteger información confidencial en la nube del administrador (cifrado de extremo a extremo) ¿Sería mejor aplicar contraseñas o frases de contraseña más complejas? [duplicar]