On Tue, 6 Nov 2001 jove_at_gaza.halo.nu 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
Received on Nov 09 2001
Intro
