From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-12-22 01:18:01
Daryle Walker wrote:
> On 12/21/04 1:20 AM, "Rene Rivera" wrote:
>>Daryle Walker wrote:
>>>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.
They do have knowledge of what you have. They have statistical
knowledge, and that is all they need to mount an attack. For example, if
you are building a ZIP for attack you know that more than 95% of the
people will be running Windows. You also know that part of those, say
50%, will run WinXP or better. And part of that, say 80%, will use the
built in Microsoft ZIP extractor. So for the current 8162, as of today,
Boost ZIP downloads you can reasonably expect to hit 3100 systems.
Case in point...
"Other vulnerabilities reported Tuesday lie in how Windows XP and
Windows Server 2003 handle compressed files in the .zip format. Users
enticed to a malicious Web site with specially crafted ZIP files, or fed
the same by e-mail, could see their PCs grabbed by attackers."
InformationWeek > Microsoft Security > Microsoft Patches 21 Bugs In
Windows, Exchange, Office > October 13, 2004
>>>An archive with executable code attached adds a potential attack vector with
>>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
> 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.
Bingo :-) The algorithms that make up the ZIP format are some of the
worst in the LZ class. The program that I used to generate that EXE uses
a much better, in compression and decompression, algo called LZMA. See
http://www.7-zip.org - And can create "solid" archives, ala
tar/(gz|bzip). And the decompression algo code is very small, compared
to the overall size of the archive.
> self-extracting code makes no difference about that, the superior archiving
> code can be provided by separate programs which the user can obtain.
True.. I could have created a *.7z archive and made people install the
extractor. But the original point was to provide the same convenience as
the in-built ZIP in WinXP. That is to have a fast extracting archive
available on machines that do not, or can't, have another extractor
installed. (re: Dave's original complaint) The gains in archive size
>>>(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.
Correct, which is why I said "one way" :-) But it is the currently only
known way that satisfies Dave's original wish/request/complaint.
> So the question is if it's worth the risk.
The argument that I've been explaining, and which Richard Peters
summarized very well, is that it's a risk equivalent to the posting of
the ZIP archive we already have. And a risk 1117 people have already
>>>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
Not considering the entire process is the _biggest mistake_ people make
when attempting to secure something. Attackers will attack the weak
points, so if you have one weak point your entire process is insecure.
For examples, horror stories, and more see Greg Schneier's web site and
research, like the "Applied Cryptography" book.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk