in reply to Re: Candidate for a new "Evil Uses For Perl" section.
in thread Candidate for a new "Evil Uses For Perl" section.

GIF offers good possibilities for this sort of thing. Although Perl::Visualize doesn't seem to take advantage of this feature of the format, one interesting thing about GIF is that after the image data has finished, all subsequent contents of the file are ignored by renderers. Many image editors take advantage of this by allowing you to add a short textual "comment" to GIF images, but in fact, arbitrary binary data can be shoved there.

ZIP has even more potential for fun though. ZIP stores its "header" at the tail end of the file. This is a throwback to the world of floppy disks. Sometimes a ZIP file you were creating would span multiple disks, and the zip program would prompt you to insert disk after disk. Only after the final piece of compressed data had been written was the zip program actually able to build the header. Thus the header got written on the last disk (not the first), at the tail end of the file.

And so, you can actually add arbitrary data to the beginning of a ZIP file and it will be ignored when decompressing. (zip2exe tools take advantage of that.)

Assuming that foo.gif is a valid GIF file, and foo.zip is a valid ZIP file, then:

cat foo.gif foo.zip > foo.gif_zip

Will create a file that is both a valid GIF file and a valid ZIP file.

Similarly, if foo.pl is a Perl script that does not read from *DATA, then the following also works:

echo "__DATA__" > middle.txt && \ cat foo.pl middle.txt foo.zip > foo.pl_zip && \ rm middle.txt

Of course, it is also possible to write foo.pl so that it does read from *DATA and somehow uses the compressed data found there. Plenty of potential there.

Replies are listed 'Best First'.
Re^3: Candidate for a new "Evil Uses For Perl" section.
by ambrus (Abbot) on Feb 16, 2012 at 11:49 UTC
Re^3: Candidate for a new "Evil Uses For Perl" section.
by mr_mischief (Monsignor) on Jul 24, 2014 at 20:07 UTC

    Comments and content-length limits of graphics formats and the like are sometimes used nefariously. In some web applications, you can easily upload a GIF file (or in others a file with the .gif extension which is assumed to be safe since it's that extension) but not something that looks like a PHP script (or not that has the .php extension in some cases).

    Since GIF allows the trailing content and PHP passes data that's not within its tags through to output unchanged, some applications will be fooled into accepting GIF files with PHP inside which act as both GIF and PHP scripts. Then the other half of the attack is just to convince the system to treat it as PHP, which for the purposes of this post is left as an exercise.