[PERDON POR EL PAPIRO]
aunque no le creo ni un 0.1% al experto, vengo a decir que si existe una pequeñisima probabilidad de infectar algo a traves de un mensaje que solo llega al correo o que no es exactamente un ejecutable.
para hacerlo, hay que tener sumamente claro cual es el objetivo, exactamente que programa recibira el correo por ejemplo, y cuales debilidades tiene ese programa, combinacion que no es facil de conseguir, y cualquier desviacion minima, por ejemplo una version minimamente distinta del objetivo, puede hacer que falle.
funciona? bueno, se ha hecho antes, en los primeros tiempos, cuando los virus se transmitian de diskette en diskette, o cuando el gusano de una precaria internet paralizo una gran cantidad de servidores.
como se hace? aca esta el truco, la mensajeria actual ha evolucionado tanto, que un cliente de correo ejecuta rutinas para interpretar y decodificar parte de los mensajes, y ahi esta el peligro, porque eso se hace sin dar ningun click (en celulares es un poco mas compleja la cosa). imaginemos en un ejemplo teorico, que el correo trae un adjunto de una imagen en formato bmp. uno de las formas de compresion del bmp es indicar el valor de un pixel y cuantas veces viene repetido este pixel en la imagen, por ejemplo, una linea negra de la imagen, podria ser el valor RGB(0, 0, 0) x 2800, suponiendo que tiene 2800 pixeles de ancho.
como se ataca? se construye una imagen bmp que pueda explotar una deficiencia concreta del decodificador, que de alguna forma esta mal construido, y por ejemplo, en vez de decir lo anterior, dice RGB(0, 0, 0) x 280000000.
un decodificador mal construido podria sobreescribir el stack, y en muchas arquitecturas y compiladores, en el stack se guarda la direccion de retorno de las subrutinas, por lo que en vez de devolverse a donde fue llamado, puede saltar a donde uno le indique, y si ademas en ese mismo stack ponemos codigo de maquina para que salte ahi y haga algo, recordando que en ese momento estamos en modo kernel, voila, tenemos un pedazo de codigo que se ejecuta sin haber dado explicitamente ejecutar a ninguna aplicacion.
esto se ha hecho, y de hecho, por ejemplo la funcion gets de c tiene miles de warnings porque potencialmente puede sobreescribir el stack si leemos algo muy grande y se ha usado para hacer exactamente lo que digo.
es un trabajo gigantesco, y no lo veo justificable en este caso, pero es 100% real no fake 1-link-download
pollo fuente, aparte de la fcfm, en los tiempos en que los programadores eran dioses
http://www.cs.unc.edu/~jeffay/courses/nidsS05/attacks/seely-RTMworm-89.html
3) version of the
finger server is a really trivial program: it reads a request from the originating host, then runs the local
finger program with the request as an argument and ships the output back. Unfortunately the
finger server reads the remote request with
gets(), a standard C library routine that dates from the dawn of time and which does not check for overflow of the server's 512 byte request buffer on the stack. The worm supplies the
finger server with a request that is 536 bytes long; the bulk of the request is some VAX machine code that asks the system to execute the command interpreter
sh and the extra 24 bytes represent just enough data to write over the server's stack frame for the main routine. When the main routine of the server exits, the calling function's program counter is supposed to be restored from the stack, but the worm wrote over this program counter with one that points to the VAX code in the request buffer. The program jumps to the worm's code and runs the command interpreter, which the worm uses to enter its bootstrap.
[PERDON POR EL PAPIRO]