Previous Entry Share Next Entry
A follow up to the Bash Exploit and SELinux.
danwalsh
One of the advantages of a remote exploit is to be able to setup and launch attacks on other machines.

I wondered if it would be possible to setup a bot net attack using the remote attach on an apache server with the bash exploit.

Looking at my rawhide machine's policy

sesearch -A -s httpd_sys_script_t -p name_connect -C | grep -v ^D
Found 24 semantic av rules:
   allow nsswitch_domain dns_port_t : tcp_socket { recv_msg send_msg name_connect } ;
   allow nsswitch_domain dnssec_port_t : tcp_socket name_connect ;
ET allow nsswitch_domain ldap_port_t : tcp_socket { recv_msg send_msg name_connect } ; [ authlogin_nsswitch_use_ldap ]


The apache script would only be allowed to connect/attack a dns server and an LDAP server.  It would not be allowed to become a spam bot (No connection to mail ports) or even attack other web service.

Could an attacker leave a back door to be later connected to even after the bash exploit is fixed?

# sesearch -A -s httpd_sys_script_t -p name_bind -C | grep -v ^D
#

Nope!  On my box the httpd_sys_script_t process is not allowed to listen on any network ports.

I guess the crackers will just have to find a machine with SELinux disabled.

  • 1
I guess we'll just have to settle for delivering HTTPS private keys and LDAP queries back to HQ over port 53?

As you correctly pointed out my I had the authlogin_nsswitch_use_ldap boolean turned on. I must have turned it on during testing. I can easily turn it off executing

# setsebool -P authlogin_nsswitch_use_ldap 0

BTW, this is off by default, so most apache servers with setenforce 1 would have been protected and the cgi scripts would not have been able to communicate with the ldap database.

I am not an httpd admin so I am not sure where all of the locations of the HTTPS private keys are stored. But googling showed me these locations.

/etc/httpd/conf/ssl.crt/ as the location where certificates will be stored
/etc/httpd/conf/ssl.key/ as the location where the server's private key is stored.
/etc/httpd/conf/ca-bundle/ as the location where the CA bundle file will be stored

These are labeled httpd_config_t, which is not readable by cgi scripts running as httpd_sys_script_t.

As you point out the cgi scripts could communicate back to the HQ Port over port 53, and if the admin had labeled content as apache pages, then the cgi script could read it. But it is a hell of a lot more confined then setenforce 0.



Kind of offtopic but still SElinux related

Hello, Dan!

I am sorry to address you here and not in bugzilla, but I am not sure if what I've ran into is a bug - so writing here. Would you please give me a hint how to resolve the following SElinux related problem?

I need to allow write permission for the directory via ftp (web developer needs that).

Here is what I have:

CentOS Linux release 7.0.1406 (Core)
selinux-policy-targeted-3.12.1-153.el7_0.13.noarch
nginx-1.7.10-1.el7.ngx.x86_64
vsftpd-3.0.2-9.el7.x86_64

Currently the permissions and context is the following:

# ls -dZ /var/www/html/dver/public/
drwxrwxr-x. nginx nginx system_u:object_r:httpd_sys_rw_content_t:s0 /var/www/html/dver/public/

# getsebool -a | grep ftpd
ftpd_anon_write --> off
ftpd_connect_all_unreserved --> off
ftpd_connect_db --> off
ftpd_full_access --> on
ftpd_use_cifs --> off
ftpd_use_fusefs --> off
ftpd_use_nfs --> off
ftpd_use_passive_mode --> off
sftpd_anon_write --> off
sftpd_enable_homedirs --> off
sftpd_full_access --> off
sftpd_write_ssh_home --> off

Everything is fine, directory is writeable. But I do not like the 'ftpd_full_access --> on' situation. I cannot assess the possible danger of having it enabled though. If it is OK - then my question is renedered null and void :)

So what I tried to do is to set the context of directory in question to 'public_content_rw_t' and disable 'ftpd_full_access'. According to manual, 'public_content_rw_t' is OK to use both for ftp and web server. But after doing so everything was broken - here is the log and audit2why output:

# cat audit.log | audit2why
type=AVC msg=audit(1427205840.506:111500): avc: denied { write } for pid=12169 comm="vsftpd" name="public" dev="vda2" ino=916858 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:public_content_rw_t:s0 tclass=dir

Was caused by:
Unknown - would be allowed by active policy
Possible mismatch between this policy and the one under which the audit message was generated.

Possible mismatch between current in-memory boolean settings vs. permanent ones.

type=AVC msg=audit(1427205893.039:111510): avc: denied { write } for pid=12190 comm="vsftpd" name="public" dev="vda2" ino=916858 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:public_content_rw_t:s0 tclass=dir

Was caused by:
Unknown - would be allowed by active policy
Possible mismatch between this policy and the one under which the audit message was generated.

Possible mismatch between current in-memory boolean settings vs. permanent ones.

So I had to set everything back to 'httpd_sys_rw_content_t' and 'ftpd_full_access --> on' but still in doubt why it throws the error like that with 'public_content_rw_t' and disabled 'ftpd_full_access'...

I appreciate your reply.

Re: Kind of offtopic but still SElinux related

Set it to public_content_rw_t and ftpd_anon_write should work.

  • 1
?

Log in