Your message dated Tue, 7 Nov 2017 14:30:43 +0200 with message-id <20171107123043.rodsna253kg4ol5m@localhost> and subject line Re: Bug#881041: gzip/gunzip: fails to preserve filename has caused the Debian Bug report #881041, regarding gzip/gunzip: fails to preserve filename to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 881041: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881041 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: gzip Version: 1.6-5+b1 Severity: serious Tags: Security Dear Maintainer, say I will gzip a file named sample_name. As result I get a new packed file sample_name.gz. When gunzipping this file the result is a file named sample_name. That is the expected result and in no way surprising or objectionable. But when I rename sample_name.gz to disguised_name.gz and than gunzip it, the result is a file withe the new name disguised_name. The original filename will not be preserved. Even if I look into the file with gunzip -l, I will not see the original filename. This might be intentional behaviour, but it is somewhat surprising - and it might lead to dangerous results! In fact, this behaviour is currently actively exploited to bypass content checks on MTA's and deliver trojans via mail to their intended victims. The problem is, that other (un)zipping tools, e.g. file-roller or nearly each and every unzipping tool under Windows don't show the same behaviour as gunzip, but unzip the file to it's original filename. The scenario is as follows: a trojan horse named trojan.exe will be gzipped. The resulting file will be renamed trojan.pdf.gz and will then be sent via mail to some target address. The MTA uses e.g. Amavis to look into the attachment with gunzip -l, sees an obviously harmless filename trojan.pdf and let it pass. The recipient unzips the file, expects a pdf, but gets an executable, doubleclick... This scenario will not work with any other zipping tool than gzip! As said before, this behaviour might be intentional; even more, there might be scripts in the wild, which count on this behaviour and would be broken, if it is changed. But at least the list command gzip -l resp. gunzip -l should show the real content of the zipped file and not just the filename with the .gz stripped.
--- End Message ---
--- Begin Message ---On Tue, Nov 07, 2017 at 11:56:56AM +0100, Georg Herrmann wrote: >... > This might be intentional behaviour, but it is somewhat surprising - > and it might lead to dangerous results! In fact, this behaviour is > currently actively exploited to bypass content checks on MTA's and > deliver trojans via mail to their intended victims. > > The problem is, that other (un)zipping tools, e.g. file-roller or > nearly each and every unzipping tool under Windows don't show the same > behaviour as gunzip, but unzip the file to it's original filename. gzip is a compresson tool, not an archiving tool. .tar.gz would be the equivalent to .zip > The scenario is as follows: a trojan horse named trojan.exe will be > gzipped. The resulting file will be renamed trojan.pdf.gz and will > then be sent via mail to some target address. > > The MTA uses e.g. Amavis to look into the attachment with gunzip -l, > sees an obviously harmless filename trojan.pdf and let it pass. The > recipient unzips the file, expects a pdf, but gets an executable, > doubleclick... Sounds more like a bug in the virus checker. > This scenario will not work with any other zipping tool than gzip! Other compressors like e.g. bzip2 or xz behave exactly the same as gzip. >... > But at least the list command gzip -l resp. gunzip -l should show the > real content of the zipped file and not just the filename with the .gz > stripped. Even if the file format would allow it, this wouldn't make sense. Your "real contents" would be whatever the person/tool who created the trojaner set there. The most trivial way to circumvent what you request would be: mv trojan.exe trojan.pdf gzip trojan.pdf cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
--- End Message ---
