On Mon, 2 Sep 1996, Bill Stewart wrote:
The key to the success is that the application in question has to be compromised to respond to these codes, either by design or by hacking. Either way the individual responsible must modify the execution mechanism, not just the data itself.
A well-written program is hard to exploit, but badly written programs can often be exploited in ways that allow execution of untrusted code. For instance, the fingerd bug exploited so spectacularly by Robert Morris handed a program more input that it was ready to accept, and the program stupidly kept writing the input into the array, past the end, and out into the stack, where it could be later interpreted as executable code.
That is one instance where it was obscure and workable. I am not familiar with the UNIX binary map, but in the Intel DOS world (includes Windows to a large degree), the stack generally lies at the top of DSEG, not CSEG and flows down. Older incarnations of x86 allowed for such wonders as: push ds push cs pop ds [ series of writes ] pop ds and viola, self modifying code by one method. Ugly, but it works. Variations on the same theme exist, now that Intel does not allow direct manipulation of the IP anymore. It's not that difficult to do. Some of the digital audio work I was involved in several years ago required modifying code sequencing on the fly to accomodate time delays and different types of processor performance. Intel binaries are not difficult to modify directly - especially when they are DOS binaries (note the plethora of viruses in the medium). Even good code can be reworked without having source. One of the tricks is to grab the intial JMP off the binary header and point it down past the bottom of the existing binary towards the code you have added. This way on startup DOS does not truncate the new binary size via Function 31h. Now all you have to do is mudge the read section and look for your trigger before executing the additional code. What I have just described is a very simplistic viral mechanism.
If a popular GIF or JPEG interpreter was written that badly, you could possibly devise a GIF that lies about how big it is and encourages the program to scribble on its stack. Now, there probably aren't any like that, and it'd probably have to be Netscape or MSIE or Lview to be widespread enough to make an attack like that worthwhile. (I'd bet on MSIE, of the three of them :-) Does Microsoft have some sort of Really Cool Extension to JPEG, allowing Macros for Self-Modifying JPEGs, trying to out-do Netscape's animated GIFs?)
It wouldn't surprise me.
Let's see -current examples of computing items with this kind of a "feature"... magic cookies, macros, OLE, DDE, MS Objects, JAVA, and the list keeps growing.
Back when Good Times came out, everyone denied that it was possible for there to be any risk from a text file (though, as I pointed out, escape-sequence hacks have been used occasionally for over 15 years), and not long after that, the MSWord Macro Viruses started appearing. Bad Code can't always be hacked usefully, but it can always be hacked...
# Thanks; Bill # Bill Stewart, +1-415-442-2215 stewarts@ix.netcom.com # <A HREF="http://idiom.com/~wcs"> # You can get PGP software outside the US at ftp.ox.ac.uk/pub/crypto
Escape sequence hacking in DOS has been done since the day ANSI.SYS came out to play. IT was a quick and dirty trick to send escape sequence laden files to the unsuspecting and ask them to type them to the screen. Then the fun began. When you stop and think about it though, any application that functions as a data engine of some type is susecptible at some level to this form of attack. The issue is really which method to employ that will give you ROI. ...Paul