From: Daryle Walker (darylew_at_[hidden])
Date: 2004-12-21 18:29:16
On 12/21/04 1:20 AM, "Rene Rivera" <grafik.list_at_[hidden]>
> Daryle Walker wrote:
>> But standard archive formats are not executable in and of themselves.
> As I mentioned elsewhere, that is irrelevant.
Yes it is. I'm talking about extraction programs that the user has versus
one that the creator/cracker provides.
>> Expanding a passive archive won't initiate any attack vectors for mal-ware.
> Yes it can. And has been historically, re: tiff, png, jpeg, shown that
> bugs in non-embeded expanders can be exploited even with "passive" archives.
I knew about this counter-argument. But the creator/cracker doesn't have
knowledge of what manipulating program you have, so s/he has no guarantee
that the bug will execute. With a self-extracting archive, s/he generally
does have a guarantee that her code will run.
>> An archive with executable code attached adds a potential attack vector with
>> dubious benefit.
> Do you consider the following a dubious benefit:
> * A guaranteed extraction performance.
> * A guaranteed construction performance.
> * A 200% compression improvement. (ZIP = 17.7M, EXE = 8.5M) And hence a
> download improvement.
Making an archive self-extracting means adding bytes, for the executable
code. How can the archive get smaller? The only way that I know of was if
the compression routine from the first archive sucked. Adding
self-extracting code makes no difference about that, the superior archiving
code can be provided by separate programs which the user can obtain. (The
exception is if the self-extracting code takes the dangerous step of being a
part of the actual compressed data, and not just tacked onto the end of the
>> (The real problem is that the OP's un-zipper sucked
>> performance-wise, but an embedded one may be just as bad. The fix is to use
>> a better extractor.)
> Yes. And a self-extractor is one way to provide such a better extractor.
But not the only way. So the question is if it's worth the risk.
>> Whether or not the files _within_ the archive have been perverted is a
>> separate matter from what I originally talked about.
> But the executable part of a self-extractor is "within" the archive. It
> is attacked the same way you would the rest of the archive content.
Your talking about all the data at all conceivable times of any use. I'm
talking about only the self-extraction code only at expansion time, leaving
the security of the expansion of the archive proper afterwards as a separate
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk