En un sistema POSIX, ¿existe la posibilidad de que un archivo no ejecutable y de solo lectura (también conocido como modo 444) ejecute código malicioso en una máquina?
Si es así, ¿puedes explicar cómo lo haría?
Si, algo solo tiene que ejecutarlo. El indicador X indica al shell que puede ejecutarse directamente, pero eso no impide que otros programas lo ejecuten si saben cómo hacerlo.
Por ejemplo, si tiene un archivo a.sh que no es ejecutable en el shell, puede ejecutarlo llamando a bash a.sh (que le dice a bash explícitamente que lo ejecute). Si tiene un archivo no ejecutable a.py , puede ejecutarlo llamando a python a.py . Me imagino que también hay una forma de decirle al sistema operativo que ejecute un archivo ELF binario, pero no conozco el comando de inmediato.
También hay toda una clase de cosas que no requieren que hagas nada en particular para hacer que ejecute código malicioso. Los archivos PDF y Adobe Flash en particular han tenido algunos agujeros bien conocidos que permitieron el simple hecho de leer un archivo para ejecutar código malicioso. También hay algunos archivos que, en lugares específicos, y se ejecutan automáticamente (especialmente en Windows). Además, si el archivo está comprimido, puede contener un virus de desbordamiento de búfer para el descompresor. El archivo también puede ser aún más malicioso, aprovechando un error aún desconocido en el sistema de archivos u otra cosa realmente de bajo nivel.
Conclusión: la única forma de garantizar que algo no infecte su computadora es nunca hacer nada con nada.
Supongamos que tiene el archivo myscript que contiene lo siguiente:
#!/bin/bash
echo "Hello, World!"
Si hace que este archivo sea ejecutable y lo ejecute con ./myscript, entonces el kernel verá que los dos primeros bytes son # !, lo que significa que es un archivo de script. El kernel utilizará el resto de la línea como intérprete y pasará el archivo como su primer argumento. Por lo tanto, se ejecuta:
/bin/bash myscript
y bash lee el archivo y ejecuta los comandos que contiene. Otra forma de ejecutar un archivo sin ejecutar el conjunto de bits es:
#. myscript
un punto seguido de un espacio y luego el nombre del archivo.
Por lo tanto, para que bash (o cualquier intérprete que requiera su script) para "ejecutar" el script, solo necesita poder leer el archivo.
Por lo tanto, para los scripts, el bit de ejecución lo hace un poco más conveniente para ejecutarlo. Siempre que bash sea ejecutable, siempre puede ejecutar bash con el archivo de script como argumento
Esto puede ser cierto no solo con scripts como los otros ejemplos que se muestran en todas las respuestas. Básicamente, si el software que lee un archivo tiene un error, cada archivo es un vector para la ejecución de código malintencionado, utilizando una amplia variedad de técnicas (desbordamiento, corrupción de memoria, ejecución de software arbitraty ...). Ejemplos:
Un archivo en sí puede no ser peligroso simplemente sentado allí. Pero dependiendo del programa que intentará leerlo, podría causar problemas. Además, si se puede leer el archivo, se puede copiar. Por lo tanto, se podría copiar y cambiar de nombre a un archivo ejecutable.
Entonces, digamos que está utilizando DOS / Windows y tiene un archivo something.txt y lo copia en un archivo llamado something.bat ahora puede ejecutarlo.
Si dice un archivo HTML (o contenido html) puede cargarlo en su navegador y si su navegador tiene una vulnerabilidad en Javascript, ese programa puede causar daño.
En teoría, si el archivo está allí, podría ser peligroso, si por alguna razón la tabla de asignación de archivos (FAT) para el sistema de archivos tiene algunos problemas y está ejecutando un programa, debido a una fragmentación incorrecta, podría saltar a donde se encuentra su archivo malicioso y ejecute dicho código. Este tipo de acciones en algunos sistemas operativos se pueden realizar a través de un desbordamiento de búfer.
Sí, puedes. El ejemplo clásico de los binarios es usar el intérprete de ELF como se muestra en el siguiente ejemplo.
$ cp /bin/ls /tmp/ls
$ chmod a-x /tmp/ls
$ /lib/ld-linux.so.2 /tmp/ls
O para sistemas x86-64:
$ /lib64/ld-linux-x86-64.so.2 /tmp/ls
Lo mismo ocurre con los scripts de shell.
$ echo "#!/bin/bash" > /tmp/hello
$ echo "echo 'hello world" >> /tmp/hello
$ bash /tmp/hello
Estos son ejemplos básicos cuando tenemos un nuevo auditor o gerente de riesgos u oficial de seguridad que piensa que necesitamos arreglar las cosas. La resolución de esto es seguir la ruta de SELinux en los sistemas Linux, ya que también restringe otras rutas de escalada como otras también se mencionaron.