?

Log in

No account? Create an account

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.



  • 1