Bug 1029710 - Amavisd fails to identify attached zipped files with .exe extensions
Amavisd fails to identify attached zipped files with .exe extensions
Status: CLOSED WORKSFORME
Product: Fedora EPEL
Classification: Fedora
Component: amavisd-new (Show other bugs)
el6
i686 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Juan Orti
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-12 19:49 EST by Steve Tindall
Modified: 2017-12-12 09:48 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-12-12 09:48:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Modified amavisd.conf (37.34 KB, text/plain)
2014-07-03 18:46 EDT, Steve Tindall
no flags Details

  None (edit)
Description Steve Tindall 2013-11-12 19:49:14 EST
Description of problem:

Mail attachments containing zipped files with .exe extensions are not properly identified due to a failure of 7za (p7zip) as called by amavisd to correctly list the contents of the zipped file. Based on maillog errors, the failure appears to be due to an improperly composed 7za option, specifically -w not being separated from the target by a separator (e.g., space character).

Manually executing 7za using the options noted in the maillog error (see below) demonstrates the need to insert a separator between the -w option and the target.

  Fails: $ 7za l -slt -w./contains_exe.zip

  Works: $ 7za l -slt -w ./contains_exe.zip

Also, this issue may be specific to EL6. This issue came to my attention because an EL6 mail server acting as a Backup MX for an EL5 mail server was forwarding zipped exe attachments, which were correctly identified and quarantined on the EL5 system.


Version-Release number of selected component (if applicable):

# uname -rpmi
2.6.32-358.23.2.el6.i686 i686 i686 i386

# rpm -q amavisd-new p7zip
amavisd-new-2.8.0-4.el6.noarch
p7zip-9.20.1-2.el6.i686


How reproducible:

Very. Observed on 3 EL6 mail servers.


Steps to Reproduce:

1. Install/configure postfix, amavisd-new, clam\*, etc.
2. Create a test attachment:
   $ touch test.exe
   $ 7za a -tzip test_exe.zip test.exe
3. Send a mail with test_exe.zip attached
4. Check /var/log/maillog for the specific error


Actual results:

 From /var/log/maillog:

Nov 12 17:17:46 Mail amavis[1568]: (28807-12) (!)run_command: child process [1568]: run_command: failed to exec /usr/bin/7za l -slt -w/var/spool/amavisd/tmp/amavis-20131112T051218-28807-HPbWePoN/parts -- /var/spool/amavisd/tmp/amavis-20131112T051218-28807-HPbWePoN/parts/p002: 13 at /usr/sbin/amavisd line 4062.

Nov 12 17:17:46 Mail amavis[28807]: (28807-12) (!)Decoding of p002 (Zip archive data, at least v1.0 to extract) failed, leaving it unpacked: do_7zip: can't get a list of archive members: exit 6;  at (eval 117) line 781.


Expected results:

Identify zipped exe file as such.


Additional info:

It may not be relevant to the observed error, but 8 months ago, amavisd-new and clam\* were converted from RepoForge/RPMforge versions to EPEL versions. Except for a few initial hiccups, the mail servers have been running without apparent issues until the current 7za issue was observed.
Comment 1 Steve Tindall 2013-11-30 13:16:09 EST
Looks like this was caused by an SELinux policy issue.

With Enforcing policy, an avc denial was observed when amavisd attempted to initiate scanning of a zipped file:

 type=AVC msg=audit(1385822144.846:122761): avc:  denied  { execute } for  pid=18479 comm="amavisd" name="bash" dev=dm-0 ino=131411 scontext=system_u:system_r:amavis_t:s0

##########

Moving the system to Permissive mode allowed listing of the zipped file′s contents by 7za as called by amavisd. Several amavisd and 7za avc denials appeared in the audit log as a result:

 type=AVC msg=audit(1385822245.350:122763): avc:  denied  { execute } for  pid=18520 comm="amavisd" name="bash" dev=dm-0 ino=131411 scontext=system_u:system_r:amavis_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file

 type=AVC msg=audit(1385822245.350:122763): avc:  denied  { read open } for  pid=18520 comm="amavisd" name="bash" dev=dm-0 ino=131411 scontext=system_u:system_r:amavis_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file

 type=AVC msg=audit(1385822245.502:122764): avc:  denied  { search } for  pid=18521 comm="7za" name="/" dev=sysfs ino=1 scontext=system_u:system_r:amavis_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir

 type=AVC msg=audit(1385822245.502:122764): avc:  denied  { read } for  pid=18521 comm="7za" name="cpu" dev=sysfs ino=22 scontext=system_u:system_r:amavis_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir

 type=AVC msg=audit(1385822245.502:122764): avc:  denied  { open } for  pid=18521 comm="7za" name="cpu" dev=sysfs ino=22 scontext=system_u:system_r:amavis_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=dir

##########

The Fix:

Enabling an SELinux policy boolean and implementing local amavisd SELinux policy allowed scanning of zipped files in Enforcing mode:

1)  # setsebool -P antivirus_can_scan_system 1

2)  # cat localamavisd.te

    module localamavisd 1.0;

    require {
	    type amavis_t;
	    type shell_exec_t;
	    class file execute;
    }

    #============= amavis_t ==============
    allow amavis_t shell_exec_t:file execute;

##########

Without the antivirus_can_scan_system boolean set, additional amavisd and 7za avc denials were observed (see above), which could be corrected using local policy, but it was much simpler to enable antivirus_can_scan_system.

With the two listed SELinux policy changes, this issue is resolved locally. It may be desirable to incorporate changes in SELinux policy module amavis 1.10.3 to globally resolve the attachment scanning issue observed here.
Comment 2 Steve Tindall 2013-12-19 19:23:27 EST
This issue also applies with the recently updated amavisd-new-2.8.0-8.el6.noarch package installed.

Removal of localamavisd (see above) SELinux module causes amavisd to allow mail with an attached, zipped exe file to be delivered.

Reinstallation of localamavisd allows amavisd to correctly identify and quarantine the mail.
Comment 3 Juan Orti 2014-06-27 11:19:56 EDT
I cannot reproduce the bug with these versions:

amavisd-new-2.8.0-8.el6.noarch
selinux-policy-3.7.19-231.el6_5.3.noarch
selinux-policy-targeted-3.7.19-231.el6_5.3.noarch

# semodule -l | grep amavis
# semodule -l | grep virus
antivirus     1.0.0

I don't have any SELinux module called localamavisd, is it a custom module?
Comment 4 Steve Tindall 2014-07-01 19:13:17 EDT
The initial "Description" (see above) may cause some confusion as to what bug I am describing. Initially, I did not recognize the failure of amavisd to run 7za as a SELinux denial and then in Comment 1 described the avc denial issues causing the failure of 7za to list the contents of the zipped file.

On a macro level, I define the bug as amavisd failing to quarantine a mail with a zipped exe attachment under SELinux Enforcing Policy.

By failure to reproduce the bug, do you mean that you created a zipped exe file (as detailed above in Description), attached it to a mail, sent the mail and observed the mail being quarantined/rejected under Enforcing Policy?

Also, the sender should get a rejection notice and a maillog entry containing "...Blocked BANNED (.asc,contains_zip.exe)..." or similar text should be present.


Yes, localamavisd is local SELinux policy described in Comment 1 that allows 7za to be called by amavisd. With localamavisd installed under Enforcing Policy, mail with a zipped exe attachment is quarantined, whereas with localamavisd removed, the mail is transmitted without being quarantined.


Other info:

# rpm -q amavisd-new p7zip selinux-policy selinux-policy-targeted
amavisd-new-2.8.0-8.el6.noarch
p7zip-9.20.1-2.el6.i686
selinux-policy-3.7.19-231.el6_5.3.noarch
selinux-policy-targeted-3.7.19-231.el6_5.3.noarch

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted
Comment 5 Juan Orti 2014-07-03 16:20:39 EDT
(In reply to Steve Tindall from comment #4)
> On a macro level, I define the bug as amavisd failing to quarantine a mail
> with a zipped exe attachment under SELinux Enforcing Policy.

I'm also testing on the same SELinux policy version in enforced mode.

# rpm -q amavisd-new selinux-policy selinux-policy-targeted
amavisd-new-2.8.0-8.el6.noarch
selinux-policy-3.7.19-231.el6_5.3.noarch
selinux-policy-targeted-3.7.19-231.el6_5.3.noarch

# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

# semanage boolean -l |grep virus
antivirus_use_jit              (off  ,  off)  Determine whether can antivirus programs use JIT compiler.
antivirus_can_scan_system      (off  ,  off)  Allow antivirus programs to read non security files on a system

> > By failure to reproduce the bug, do you mean that you created a zipped exe
> file (as detailed above in Description), attached it to a mail, sent the
> mail and observed the mail being quarantined/rejected under Enforcing Policy?

I have zipped a couple of exe files with the method you describe, and they are correctly uncompressed and blocked.

> 
> Also, the sender should get a rejection notice and a maillog entry
> containing "...Blocked BANNED (.asc,contains_zip.exe)..." or similar text
> should be present.

In my tests, the sender receives an informational email with the subject "BANNED contents from you (...)"

> Yes, localamavisd is local SELinux policy described in Comment 1 that allows
> 7za to be called by amavisd. With localamavisd installed under Enforcing
> Policy, mail with a zipped exe attachment is quarantined, whereas with
> localamavisd removed, the mail is transmitted without being quarantined.

My amavis configuration is almost identical to stock, could you attach yours?
Could you test removing the localamavisd module and relabeling your system?

# semodule -r localamavisd
# touch /.autorelabel
# reboot
Comment 6 Steve Tindall 2014-07-03 18:46:22 EDT
Created attachment 914596 [details]
Modified amavisd.conf

Requested amavisd.conf

Deviations from the stock config file are preceded by "# MODIFICATION"
Comment 7 Steve Tindall 2014-07-03 18:57:12 EDT
Starting at the bottom of your comments...

The requested amavisd.conf is attached above.

As suggested, I removed the local amavisd policy, relabeled the filesystem and rebooted. A test mail with an attached zipped exe file is no longer quarantined and is passed undetected to the outgoing mail queue.

As I understand the underlying process, 7za lists the contents of the zip, amavisd identifies a file ending in exe and amavisd quarantines the mail. No viral scan (locally clamd.amavisd) is actually performed.

Is it possible that your viral scan is detecting the file and not amavisd directly?
Comment 8 Juan Orti 2014-07-05 12:33:52 EDT
Ok, I have run several tests with your config, and it blocks the delivery of the email in all the cases. The tests were with clamd enabled and disabled.

I have seen it fails to quarantine the email and to send the notification. It is because you have:

$QUARANTINEDIR = "/var/virusmails";

Change it to a folder inside /var/spool/amavisd or set the appropiate SELinux permissions:

# chown amavis:amavis /var/virusmails
# semanage fcontext -a -t antivirus_db_t '/var/virusmails(/.*)?'
# restorecon -F -r -v /var/virusmails

Does it fix your issue?
Comment 9 Steve Tindall 2014-07-07 21:53:27 EDT
Hum. This just gets stranger.

To summarize, my amavisd.conf used on your system correctly identifies and blocks a zipped exe attachment, but fails to quarantine and send notification. On my system, it fails to identify the zipped exe attachment unless I either place the system in permissive mode or use SELinux local policy defined in Comment 1 to correct the issues.


Your suggestions sounded interesting, but changing $QUARANTINEDIR as suggested results in the same failure. Here are three definitions I tired (followed by successful amavisd restarts):

1) $QUARANTINEDIR = "/var/virusmails";
2) $QUARANTINEDIR = undef;      # -Q
3) $QUARANTINEDIR = "/var/spool/amavisd/quarantine";

...where:

# ls -dZ /var/spool/amavisd/quarantine
drwx------. amavis amavis system_u:object_r:amavis_spool_t:s0 \
 /var/spool/amavisd/quarantine


Definitions: #1 is my original, #2 is the default definition and #3 is a variation of your suggestion, if I understood it correctly.

The maillog error I see using option #3 is:

 amavis[11452]: (11452-02) (!)Decoding of p002 \
  (Zip archive data, at least v1.0 to extract) failed, \
  leaving it unpacked: do_7zip: can't get a list of \
  archive members: exit 6;  at (eval 117) line 781.

I also tried using the distribution default amavisd.conf with only $mydomain and $myhostname defined/altered and it also fail to detect the zipped exe attachment.


All four tests gave basically the same message (i.e., failed to extract).


This is really strange.


Try looking at your 7za contexts:

 # ls -dZ $(which 7za)
 -rwxr-xr-x. root root system_u:object_r:bin_t:s0 \
       /usr/bin/7za

Beyond that, I would need to think about this a while for new ideas.


In case it is relavent, the system I am using for these tests is a development system configured with a mysql backend (PostfixAdmin) and mailman configured to service two custom mail lists. It runs on 32-bit Scientific Linux 6 as a virtual machine under KVM.

 # cat /etc/redhat-release
 Scientific Linux release 6.5 (Carbon)

 # uname -rpmi
 2.6.32-431.20.3.el6.i686 i686 i686 i386

 # rpm -q postfix dovecot amavisd-new clamav clamd p7zip mailman
 postfix-2.6.6-6.el6_5.i686
 dovecot-2.0.9-7.el6_5.1.i686
 amavisd-new-2.8.0-8.el6.noarch
 clamav-0.98.4-1.el6.i686
 clamd-0.98.4-1.el6.i686
 p7zip-9.20.1-2.el6.i686
 mailman-2.1.12-18.el6.i686

Note You need to log in before you can comment on or make changes to this bug.