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." http://informationweek.com/story/showArticle.jhtml?articleID=49901123 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 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.
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.
Adding 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 where incidental.
(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 taken ;-)
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 problem.
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