Bash: ¿Por qué el abastecimiento de un archivo sería menos seguro que hacerlo (ejecutar en otra sesión)?

Question

Bash: ¿Por qué el abastecimiento de un archivo sería menos seguro que hacerlo (ejecutar en otra sesión)?

#1 de Steffen Ullrich (4 votos)
#2 de JesseM (0 votos)

2

Bash: ¿Por qué el abastecimiento de un archivo sería menos seguro que si lo golpeara (ejecutándose en otra sesión)?

¿Es el caso, o lo entendí mal?

He escuchado en el contexto de obtener un sub-script de un master-script. Por ejemplo, las secuencias de comandos remotas curl y source que generan una o más secuencias de comandos (en aras de la pregunta, supongamos que todas estas secuencias de comandos son seguras y están bien).

Lo que trato de entender es por qué alguien pensaría que es menos seguro obtener el script interno, en lugar de ejecutarlo ( ~/sub-script.sh o bash ~/sub-script.sh ).

Si toda esta pregunta parece poco probable o absurda, no seas sarcástico, pero asegúrate de votar para cerrarla si puedes, ya que podría estar basada en un malentendido de mi parte o en una expresión errónea de algo más profundo. intención del hombre que dijo eso.

bash code-execution

pregunta user9303970 09.02.2018 - 17:38

fuente

2 respuestas

0

La fuente de la secuencia de comandos contamina / altera su entorno actual. Podría tener futuros efectos de sesión en el futuro. Para un ejemplo simple, imagine el siguiente escenario.

Yo (el atacante) proporciono algunas secuencias de comandos útiles que hacen lo que usted desea. Pero además, mi script deja caer un ejecutable llamado "sudo" en un directorio oculto en algún lugar. Este ejecutable cosecha y me envía a casa, sus argumentos y llama al sistema "sudo" comando. Mi script también ajusta la variable $ PATH poniendo primero mi directorio oculto.

Si ejecutas mi script en su propia shell, obtienes el efecto útil que pensabas que estabas obteniendo, y mi envoltorio oculto desapareció, pero nada más.

Si introdujo mi script en su entorno actual, la próxima vez que escriba "sudo foo", llamará a mi script de contenedor hostil, que llamará al sudo real en su nombre, pero obtendré su información. Tal vez días o semanas después.

Este es un ejemplo artificial, pero el punto es que la fuente de cambios cambia su entorno después de que se realiza el trabajo. La ejecución en su propio shell limita los cambios en el trabajo que realiza el script.

Los atacantes pueden abusar de los efectos secundarios

respondido por el JesseM 09.02.2018 - 19:40

fuente

Lea otras preguntas en las etiquetas bash code-execution

¿Un pin bitlocker se convierte en parte de la clave? ¿Podría un actor estatal MITM Encriptar la emisión de certificados para proporcionar un certificado que podrían descifrar más fácilmente?

score 4 · Accepted Answer

No conozco la declaración exacta y su contexto, así que solo puedo adivinar lo que se quería decir: si un script se obtiene en lugar de ejecutarse en un shell separado, entonces cualquier variable o función definida en este script o cualquier cambio en las variables ser visible en su shell después de que se hizo el script. Esto podría estar pensado en algunos casos (y es por eso que puede generar un script), pero también podría ser una contaminación no intencionada del entorno actual de su shell con efectos secundarios no deseados.

Por lo tanto, a menos que desee explícitamente permitir que el script realice cambios en su entorno de bash local, debe ejecutarlo como shell-script (es decir, shell separado) y no como fuente.

Y tenga en cuenta que esto no es realmente un problema de seguridad de la información: desde un punto de vista de seguridad, el script de origen y el script ejecutado en un shell separado pueden ejecutar código malicioso con los permisos del usuario.