Si conozco la arquitectura de CPU de un objetivo, ¿puedo enviar instrucciones incrustadas en una imagen?

Las instrucciones de la CPU se proporcionan en lo que se denominan opcodes , y tienes razón en que esas personas viven en la memoria como tu imagen. Sin embargo, viven en "áreas" de memoria conceptualmente diferentes.

Por ejemplo, podrías imaginar un código de operación "leer" (0x01) que lee un byte de entrada de stdin y lo coloca en algún lugar, y otro operando "agregar" (0x02) que agrega dos bytes. Algunos opcodes pueden tomar argumentos, por lo que le daremos algunos ejemplos: el opcode "read" toma un operando donde se almacena el byte que lee, y el comando "add" toma tres operandos: dos para dónde leer sus entradas y una para dónde escribir el resultado.

0x01 a1 // read a byte to memory location 0xa1
0x01 a2 // read a byte to memory location 0xa2
0x02 a1 a2 a3 // read the bytes at locations 0xa1 and 0xa2, add them,
              // and write the result to location 0xa3

Esto es típico de cómo funcionan muchas instrucciones: la mayoría de ellas solo funcionan con datos que están en la memoria, y algunas de ellas guardan nuevos datos en la memoria del mundo exterior (desde la lectura estándar, en este ejemplo, o desde la lectura un archivo o interfaz de red).

Si bien es cierto que las instrucciones y los datos en los que operan están en la memoria, el programa solo ejecutará las instrucciones. Es el trabajo de la CPU, el sistema operativo y el programa para asegurarse de que eso suceda. Cuando fallan, de hecho, puede cargar datos en el espacio de ejecución, y es un error de seguridad grave. Desbordamientos de búfer son probablemente el ejemplo más famoso de este tipo de error. Pero aparte de ese tipo de errores, esencialmente puedes pensar en el espacio de datos y el espacio de ejecución como partes separadas de la CPU.

En una computadora de juguete, usando el ejemplo anterior, la memoria puede tener un aspecto similar al siguiente:

(loc)  | Initial      | After op 1   | After op 2   | After op 3   |
0x00   | *01 a1       |  01 a1       |  01 a1       |  01 a1       |
0x02   |  01 a2       | *01 a2       |  01 a2       |  01 a2       |
0x04   |  02 a1 a2 a3 |  02 a1 a2 a3 | *02 a1 a2 a3 |  02 a1 a2 a3 |
0x08   |  99          |  99          |  99          | *99          |
...
0xa1   |  00          |  03          |  03          |  03          |
0xa2   |  00          |  00          |  04          |  04          |
0xa3   |  00          |  00          |  00          |  07          |

En ese ejemplo, el asterisco ( * ) apunta al siguiente código de operación que se ejecutará. La columna de la izquierda especifica la ubicación de memoria de inicio para esa línea. Así, por ejemplo, la segunda línea nos muestra dos bytes de memoria (con los valores 01 y a2 ) en las ubicaciones 0x02 (explícitamente en la columna de la izquierda) y 0x03.

(Comprenda que todo esto es una gran simplificación. Por ejemplo, en una computadora real, la memoria puede intercalarse; no solo tendrá una parte de las instrucciones y una parte de todo lo demás. Lo anterior debe ser bueno suficiente para esta respuesta, sin embargo.)

Tenga en cuenta que a medida que ejecutamos el programa, la memoria en las áreas 0xa1 - 0xa3 cambia, pero la memoria en 0x00 - 0x08 no. Los datos en 0x00 - 0x08 son los ejecutables de nuestro programa, mientras que la memoria en las áreas 0xa1 - 0xa3 es la memoria que el programa utiliza para realizar el procesamiento de números.

Para volver a su ejemplo: los datos de su jpeg se cargarán en la memoria mediante los códigos de operación y serán manipulados por los códigos de operación, pero no se cargarán en su misma área en la memoria. En el ejemplo anterior, los dos valores 0x03 y 0x04 nunca estuvieron en el área de código de operación, que es lo que ejecuta la CPU; estaban solo en el área desde donde los códigos de operación leen y escriben. A menos que encuentre un error (como un desbordamiento de búfer) que le permita escribir datos en ese espacio de código de operación, sus instrucciones no se ejecutarán; simplemente serán los datos que se manipulan mediante la ejecución del programa.

Otras respuestas ofrecen una buena explicación técnica, pero permítanme intentarlo con una analogía:

  

Envíe su número de tarjeta de crédito a [email protected]

• ¿Lo leíste?

• ¿Lo hiciste?

Es más o menos lo mismo para tu CPU. Leer algo no es lo mismo que ejecutarlo.

¿Puedes enviarlos? Sí, por supuesto. Simplemente reúnalos y péguelos en algún lugar del archivo de imagen.

¿El objetivo los ejecutará? No, no a menos que ya tengas control sobre el objetivo (y así puedas poner un programa allí para leerlos y ejecutarlos), o si encuentras algún exploit en un visor de imágenes y obtienes la imagen para cargar en él.

Podrías si tu objetivo utilizara una versión de Internet Explorer de antes de agosto de 2005 para ver un JPG. O si iban a abrir un archivo PNG en Windows Media Player en Windows 98 sin actualizaciones de seguridad instaladas. Y así sucesivamente.

Había una gran cantidad de software antiguo que solía tener errores en los que, si creaba un archivo de imagen en el que la primera parte del archivo de imagen mentía escandalosamente sobre el tamaño y la ubicación de los datos de píxeles en el archivo, el software podría haga algo mal y salte accidentalmente al código en la dirección incorrecta o escriba los datos del archivo en un lugar donde debería estar el código del programa. Recuerdo que uno de estos trucos incluía un archivo cuyo encabezado decía que la imagen tenía un tamaño negativo. Probablemente no pueda hacer esto con las versiones más recientes de Internet Explorer o Edge, ya que todos conocen el problema ahora y Microsoft hizo todo lo posible por solucionarlo.

Los sistemas operativos de hoy tienen algunas medidas de protección para dificultar (pero no completamente imposible) lograr algo realmente malo si encuentra una nueva forma de hackear un programa utilizando un método como este. Las áreas de memoria se pueden configurar para que no se puedan ejecutar. Los programas tienen espacios de direcciones virtuales separados para que no puedan acceder accidentalmente a la memoria de los demás. Algunos componentes del sistema operativo se cargan en ubicaciones de memoria impredecibles, por lo que no es sencillo que los códigos malintencionados los encuentren y utilicen.

No. Los archivos de imagen, como los archivos JPEG, no ejecutan el código, simplemente se representan y muestran.

Si desea ocultar alguna información en un archivo que se llama esteganografía, pero que solo oculta la información, no ejecuta ninguna instrucción.

Para que un archivo ejecute el código, debe ser un ejecutable, o debe ser ejecutado por otro programa que lea el archivo y luego ejecute los comandos en el archivo.

En este caso, el caso poco frecuente de que una imagen pueda resultar en la ejecución de un código es si hubo un error en el software que hizo que la imagen se basara en el archivo. Esto ha sucedido en el pasado, pero es extremadamente raro. Para todos los propósitos prácticos, una imagen no puede ejecutar instrucciones.

Por supuesto, este no es el caso de los archivos PDF, Adobe Flash, etc.

Puede, SI también sabe qué pila de software tocará la imagen en el lado receptor, Y SI hay vulnerabilidades de seguridad no resueltas en esa pila de software.

Simplemente poner las instrucciones en el archivo JPEG no hace nada.

Sin embargo, si existe una forma conocida de hacer que cierta implementación exacta del lector JPEG se bloquee en un archivo JPEG con formato incorrecto de manera que se copien los datos del archivo de imagen al que no pertenecen esos datos (como, encima de las variables) que contienen información de flujo de control de programa como punteros de función o direcciones de retorno), y si las contramedidas a nivel de sistema operativo o hardware (por ejemplo, DEP) no evitan que eso suceda, existe una posibilidad realista. Tales vulnerabilidades han existido (y existen en implementaciones heredadas) en el mundo real.

Aquí hay algo para imaginar: si realmente fuera cierto que una computadora necesitaba ejecutar código de máquina dentro de una imagen para mostrarla, todo lo que hacemos con imágenes digitales apestaría .

• Para poder mostrar una imagen en la Web, tendría que tener un archivo de imagen diferente para cada arquitectura individual en la que desee mostrar la imagen. No solo tendría que cubrir los más comunes, como x86, x64 y ARM, sino también los potencialmente más oscuros que aún podrían ver su sitio web, como PowerPC y MIPS. Algunas computadoras tienen la misma arquitectura pero diferentes convenciones de llamadas (por ejemplo, x64 de Windows frente a x86_64 de Linux), por lo que también es necesario tenerlas en cuenta. No solo eso, sino que la mayoría de las PCs reaccionan de manera catastrófica si están configuradas para ejecutar código escrito para otra arquitectura, por lo que tendría que acordar un estándar por el cual el código para diferentes arquitecturas de imagen podría identificarse correctamente (y esperar que las imágenes cumplan correctamente con eso) ).
• Con eso en mente, tampoco puedes transferir imágenes entre sistemas. Casi todos los usuarios no podrían enviar imágenes tomadas desde su teléfono a una PC, especialmente a través de algo como una tarjeta SD, y los usuarios de Android tampoco podrían enviar imágenes a usuarios de iOS, o viceversa. Si quisiera enviar imágenes, tendría que convertirlas de la arquitectura del remitente a la arquitectura del receptor, lo que en realidad resulta ser un problema muy difícil en algunos pares de arquitectura.
• Algunos sistemas operativos son bastante laxos con respecto a la seguridad de ejecución (lea: Windows XP), pero otros sistemas operativos se basan en la idea de dar permisos específicos a los ejecutables sobre qué recursos pueden usar. Android, por ejemplo, le muestra un cuadro de diálogo de permisos que le indica exactamente a qué partes del teléfono debe tener acceso una aplicación antes de ejecutarla. Si Android necesita ejecutar código en las imágenes para mostrarlas, obtendrá este mismo cuadro de diálogo de permisos para cada imagen en cada sitio web con el que alguna vez se haya topado, y tendría que aceptar estos permisos antes de poder ver cómo iba a ser la imagen (ni siquiera podría mostrar una vista previa, ya que eso también tendría que ejecutar el código). / li>
• Y, por supuesto, ese código probablemente terminará con errores que hacen que la imagen no se muestre correctamente o no se vea. Por ejemplo, un simple error en la lógica del programa podría hacer que la carga de la imagen se cuelgue para siempre sin progreso.

Como lo explican las otras respuestas, aunque una imagen puede tener un código de máquina incrustado en los datos, nunca se ejecuta ningún código de máquina dentro de la imagen para que la imagen se muestre. Una buena manera de pensarlo es que, sí, un programa sí debe ejecutarse para mostrar una imagen en la pantalla, ese programa es exactamente el mismo para cada imagen (de la misma imagen). Formato) La computadora siempre aparece: solo procesa datos diferentes cada vez. Por lo tanto, el archivo de imagen solo se preocupa por incluir la parte de datos y espera que la computadora que la muestra ya tenga la parte del programa a la mano, y esa parte del programa seguramente se escribirá en la arquitectura de la computadora y se espera que haga lo correcto sin errores o errores. engaños maliciosos.

La versión corta es no, porque las computadoras (DEBERÍAN) saben la diferencia entre los datos y las instrucciones. Lo peor que DEBES poder hacer con un JPEG es algo así como una bomba zip o algo que bloquea algunas rutinas de descompresión JPEG. Un programa para cargar & mostrar un JPEG no intentará EJECUTAR ninguno de los datos en el archivo, solo leerlo y procesarlo, y si llega a algún dato inesperado no jpeg, se detendrá o se bloqueará, o simplemente mostrará una imagen realmente desordenada.

SIN EMBARGO, a veces (te estoy mirando a ti, Microsoft) las personas intentan escribir un software útil que puede ser vulnerable (por ejemplo) tratando de cargar automáticamente & muestra archivos adjuntos de correo electrónico, crea formatos de documentos que pueden contener scripts / macros, etc. y aquí es donde un archivo malintencionado puede causar daños.

El ejemplo clásico (y ahora con suerte ya no está protegido / protegido) son los archivos adjuntos de correo electrónico llamados algo así como .jpg.exe donde el archivo es realmente un ejecutable y Windows lo tratará como tal, pero porque Windows oculta la extensión (que oculta la última parte .exe), la gente ve file.jpg y hace clic en ella, lo que hace que el sistema operativo la ejecute.

Es la diferencia entre leer un libro y representar su contenido: si el libro dice "ve y golpea a alguien", no lo harás, porque las palabras (datos) en el libro no controlan. tu cerebro, aunque tu cerebro esté procesando esos datos.