On Tue, 6 Nov 2001 joveat_private wrote: > If there was some sort of buffer overflow/other way of causing the > code to function in a manner inconsistant with it's design due to the > content/formatting of the .jpg image then yes, there could be a payload > designed to be set off upon viewing of the .jpg image. Otherwise, the > .jpg image specifies (simplified) values of pixels in a compressed format > and thus the .jpg specification does not include the ability to run code > by default. The most likely route to an overflow is probably through one of the compression algorithms. Something similar to the massively compressed huge file that DoS'es antivirus scanners. Find a bug in any one of the "family of compression algorithms" supported by the standard that allows you to write 'image data' past the end of the allocated buffer. Cross-platform shellcode written to the most likely offsets for common architectures could effect a lot of boxes. I'll bet the specs aren't available online for a reason. ;] If anybody can fork me a copy, I'll work on a proof of concept. z
This archive was generated by hypermail 2b30 : Fri Nov 09 2001 - 11:02:46 PST