Zip file bypassing scan

Sat May 30 00:58:33 CEST 2015

Thomas,

I've updated 'file' package and that .zip file detected now.

I decided to check .rar files and found that decoder is unable to unpack
them during scan.

My @decoders for rar:
  ['rar',  \&do_unrar, ['unrar', 'rar'] ],

I have unrar-5.0.3-1 installed on my server.

Can you please send any rar archive through your system?
Which decoder for rar you have?
Here is the debug log record:
May 29 21:08:22  amavis[2565]: (02565-02) File-type of p002: RAR archive
data, v1d, os: Unix; (rar)
May 29 21:08:22  amavis[2565]: (02565-02) decompose_part: p001 - atomic
May 29 21:08:22  amavis[2565]: (02565-02) Expanding RAR archive p002
May 29 21:08:22  amavis[2565]: (02565-02) get_deadline do_unrar_pre -
deadline in 600.0 s, set to 420.000 s
May 29 21:08:22  amavis[2565]: (02565-02) prolong_timer do_unrar_pre: timer
420, was 420, deadline in 600.0 s
May 29 21:08:22  amavis[2565]: (02565-02) run_command: [3256]
/usr/bin/unrar v -c- -p- -idcdp --
/var/spool/amavisd/tmp/amavis-20150529T191447-02565-pRlWBcig/parts/p002
</dev/null 2>&1
May 29 21:08:22  amavis[3256]: (02565-02) open_on_specific_fd: target fd0
closing, to become < /dev/null
May 29 21:08:22  amavis[3256]: (02565-02) open_on_specific_fd: target fd1
closing, to become (65) &=13
May 29 21:08:22  amavis[3256]: (02565-02) open_on_specific_fd: target fd1
dup2 from fd13 (65) &=13
May 29 21:08:22  amavis[3256]: (02565-02) open_on_specific_fd: source fd13
closed
May 29 21:08:22  amavis[3256]: (02565-02) open_on_specific_fd: target fd2
closing, to become (65) &1
May 29 21:08:22  amavis[3256]: (02565-02) open_on_specific_fd: target fd2
dup2 from fd1 (65) &1
May 29 21:08:22  amavis[2565]: (02565-02) do_unrar: summary size: 42482,
sum of sizes: 0
May 29 21:08:22  amavis[2565]: (02565-02) Charging 42482 bytes to remaining
quota 29638424 (out of 29681000, (0%)) - by do_unrar-pre
May 29 21:08:22  amavis[2565]: (02565-02) do_unrar: no archive members, or
not an archive at all
May 29 21:08:22  amavis[2565]: (02565-02) get_deadline do_unrar - deadline
in 599.9 s, set to 420.000 s
May 29 21:08:22  amavis[2565]: (02565-02) prolong_timer do_unrar: timer
420, was 420, deadline in 599.9 s
May 29 21:08:22  amavis[2565]: (02565-02) lookup_re("RAR archive data, v1d,
os: Unix"), no matches
May 29 21:08:22  amavis[2565]: (02565-02) lookup [keep_decoded_original] =>
undef, "RAR archive data, v1d, os: Unix" does not match
May 29 21:08:22  amavis[2565]: (02565-02) decompose_part: deleting
/var/spool/amavisd/tmp/amavis-20150529T191447-02565-pRlWBcig/parts/p002
May 29 21:08:22  amavis[2565]: (02565-02) decompose_part: p002 - archive,
unpacked
May 29 21:08:22  amavis[2565]: (02565-02) get_deadline parts_decode -
deadline in 599.9 s, set to 420.000 s
May 29 21:08:22  amavis[2565]: (02565-02) prolong_timer parts_decode: timer
420, was 420, deadline in 599.9 s

Thank you.

2015-05-28 20:54 GMT+03:00 Konstantin <myownletters at gmail.com>:

> I have decoders installed. Previously all exe files in .zip were rejected.
>
> Found decoder for    .zip  at /usr/bin/7za
> Found decoder for    .exe  at /usr/bin/unrar; /usr/bin/lha; /usr/bin/unarj
> p7zip-9.20.1-2.el6.x86_64
> lha-1.14i-19.2.2.el6.rf.x86_64
>
> It seems that file-5.04-21.el6.x86_64 is the old one. But it is latest
> version available in base repo (
> # file invoice.zip
> invoice.zip: data
>
> On my ArchLinux desktop i have file-5.22-1
> $ file Downloads/invoice.zip
> Downloads/invoice.zip: Zip archive data
>
> Will look how to update it on CentOS 6.
>
> Thanks for the help.
>
>
> 2015-05-28 12:44 GMT+03:00 Andre Helwig <a.helwig at heinlein-support.de>:
>
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Update your "file" package to the latest version.
>>
>> could be that your file does not detect .zip as zip file and did't
>> unpack the zip.
>>
>> Simply check the result of "file $filename.zip" if result is Zip archive
>> data..
>>
>> Cheers
>>
>> On 05/27/2015 11:22 PM, Thomas Spuhler wrote:
>> > On Wednesday, May 27, 2015 11:13:25 PM Konstantin wrote:
>> >> Hi,
>> >>
>> >> Today I found the same behaviour with following zip file.
>> >> In $log_level=5 i see that amavis see content of zip archive
>> >> (Docs-5280.exe) but did not block it.
>> >> If I extract the Docs-5280.exe file and place it into another zip file,
>> >> that zip file is correctly identified as
>> >> containing an .exe, and rejected by the server.
>> >>
>> >> Can anyone make a test from your side?
>> >>
>> >> I have CentOS 6 with amavisd-new-2.8.0
>> >>
>> >> == THE CONTAINED EXE FILE CONTAINS TROJAN ==
>> >> Original file:
>> https://www.dropbox.com/s/b831empj0t8vz7f/invoice.zip?dl=0
>> >>
>> >> Thank you.
>> >>
>> >> 2015-04-24 1:08 GMT+03:00 Thomas Spuhler <thomas.spuhler at btspuhler.com
>> >:
>> >>> On Thursday, April 23, 2015 02:24:19 PM Brendan Zerr wrote:
>> >>>> Hello,
>> >>>>
>> >>>> This morning our mailserver (Postfix+Amavis) had a virus pass
>> through to
>> >>>> our users. The file was an .exe file within a .zip file. The server
>> is
>> >>>> configured to block .exe files with $banned_filename_re, but this one
>> >>>> slipped by. After setting $log_level to 5, it seems that the ZIP file
>> >>>> was never decoded by amavis, but allowed to pass unscanned. ClamAV
>> >>>> missed the virus as well, but it should have never made it to that
>> point
>> >>>> anyway. The strangest thing is, if I extract the .exe file and place
>> it
>> >>>> into a "new" zip file, that zip file is correctly identified as
>> >>>> containing an .exe, and blocked by the server.
>> >>>>
>> >>>> I've gone so far as to override the default zip decoding, using 7zip:
>> >>>>     @decoders = (
>> >>>>
>> >>>>         ['zip', \&do_7zip, ['7z', '7za'] ]
>> >>>>
>> >>>>     );
>> >>>>
>> >>>> and the same behaviour is exhibited.
>> >>>>
>> >>>> Versions:
>> >>>> Ubuntu 10.04
>> >>>> amavisd-new-2.6.4
>> >>>>
>> >>>> I realize this version is quite out of date, and that may be the
>> >>>> ultimate cause of the issue (working on testing this theory), but in
>> >>>> case it isn't I wanted to let someone know.
>> >>>>
>> >>>> I've made available the original and "new" zip files on Dropbox:
>> >>>> == THE CONTAINED EXE FILE IS ACTIVELY HARMFUL TO A WINDOWS HOST ==
>> >>>> Original: https://www.dropbox.com/s/modnz533k4swum7/Original.zip
>> >>>> New: https://www.dropbox.com/s/5ynitllq0ghvfqn/NewZip.zip
>> >>>
>> >>> The exe file is detected here.
>> >>> I downloaded your Original.zip from the dropbox and attached it to an
>> >>> e-mail I sent to myself.
>> >>> See the attachment what happened.
>> >>> Of course, it didn't find the virus since the exe file was blocked
>> before
>> >>> it go to the virus scanner
>> >>>
>> >>> --
>> >>> Best regards
>> >>> Thomas Spuhler
>> >>>
>> >>> All of my e-mails have a valid digital signature
>> >>> ID 60114E63
>> >
>> > Konstantin:
>> > I downloaded the zip file from your link. Attached it to an e-mail to
>> my wife's e-mail address (same
>> > server as mine) and the e-mail didn't get delivered. I got a message
>> (as admin) that it was
>> > rejected.
>> > See the details of the message in the attachment. Do you really have
>> an unzip program installed?
>> > I am using p7zip-9.20.1 for it. and for  .exe   /usr/bin/lha
>> >
>> >
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.22 (GNU/Linux)
>>
>> iQEcBAEBAgAGBQJVZuOZAAoJEAoTNwRDnEhRXDcIAJe+mVhdb6ADaHT4NVv7I5sW
>> sDz0pozLedmeidjfgLxDroGgW/DFJ0eYAcD45vnsfBsGnTpyjVX8YXOh603ffXLw
>> tHFtfxFQ8TnAojQAcURc5gGbTYsNzDBZA0bybUiyhP1eo7H5beWcpxkJLra4weLJ
>> 7qwj2r+LfiA43ayUEr5aOSr+y2nL18JeRexfUCE8wQ6OJM2LHxJ/mXdgpKM3R9xf
>> JtrFDjSHYXe7lpGtrBld5e2UbGTiQDfHCBV75WeNkzTMdxMPCWkSzLfAFXHuVXvQ
>> Cwgxr6J5niqcBnB2AE+8LiI89mFpJoYyjhn4DBdzcBVNxEUykMCG6qOQs6eO+9U=
>> =kDqy
>> -----END PGP SIGNATURE-----
>>
>>
>
>
> --
> *This message was delivered using 100% recycled electrons*.
>

-- 
*This message was delivered using 100% recycled electrons*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.amavis.org/pipermail/amavis-users/attachments/20150530/e423efac/attachment.html>