danwalsh


Dan Walsh's Blog

Got SELinux?


Previous Entry Share Next Entry
SELinux Constrains Samba Vulnerability
danwalsh
One thing that I have been a little lax about reporting is when SELinux has mitigated a vulnerability.  This past week, two Samba vulnerabilities were fixed in an Red Hat Network Update.  These  fixes were available at the same time as public disclosure of the issues, There are no currently known public exploits of Samba available. This errata fixed two bugzillas #239774 and #239429.   I would like to point out that even with these vulnerabilities being able to leverage a heap overflow to run arbitrary code on a recent RHEL is hard.

While no known Linux exploits for these vulnerabilities has been written, we believe that the executable memory process checks in SELinux would have prevented the exploit from executing writable memory.  While the exploit might be able to take advantage of a buffer overflow,  When the attacker tries to execute the code, SELinux would stop it.  SELinux prevents Samba from allocating and using memory that is both writable by the process and executable. 

If the attacker somehow got around this prevention and was able to execute commands as root:

Reviewing SELinux policy for Samba reveals that out of the box, the Samba vulnerabilities on RHEL5 were contained.  If you really wanted to do a thorough examination of SELinux policy for Samba you could use apol from setools.  

Here are the default boolean settings:

# getsebool -a | grep samba
samba_domain_controller --> off
samba_enable_home_dirs --> off
samba_export_all_ro --> off
samba_export_all_rw --> off
samba_share_nfs --> off
use_samba_home_dirs --> off
# getsebool -a |grep smb
allow_smbd_anon_write --> off
smbd_disable_trans --> off
# getsebool -a | grep nmb
nmbd_disable_trans --> off

If someone was able to use the Samba vulnerability to execute code as the root user what could they do by default?


  • Well they can read/write any files/directories labeled samba_share_t
    But that would be expected, because these were the files/directories that the user had shared.  Although this would be root access to them versus the uid of the remote user.

  • Read any files/directories labeled public_content_t

  • Read/Write /etc/samba/*

  • Read/Write /var/log/samba/*

  • Read/Write /var/spool/samba

  • Create/Read/Write files created in /tmp by Samba.  Samba can not access files created by other processes or users.

  • Read/Write /var/run/samba/*

  • Read/Write  cups configuration files

  • Can connect to the cups process

  • Make outward tcp connections to 631, 137-139, 445


    • Since it uses nsswitch, it can also connect to all the ports needed for nsswitch (kerberos, ldap)  Although not NIS.


  • Listen on incoming connections 137-139, 445

  • It can execute unix_chkpwd and update_passwd but both of those require you to know the password to run.  
    It has no direct access to the /etc/shadow file

  • It can read most files in /etc/  (Those with the default label of etc_t or etc_runtime_t)\

  • It can read most files in /usr (Those with the default label of usr_t)

  • It can update the utmp file

  • It can read an do all the code that is used in nsswitch


What can't a root exploit of Samba running under SELinux protection do by default?
    Read/Manipulate Users home directories (Where the good stuff is)
    Read/Manipulate any databases on the system
    Attack data/processes owned by other confined domains (200 in a RHEL5 machine)
    Attack other machine via the network, Other then the ports mentioned above. 
    Can not send mail to become a spam agent.
Not only that, while the attacker is trying to do evil things on your machine, your audit logs will be capturing avc messages showing you what the attacker was trying to do.  If you had setroubleshoot running, you would be receiving real time notification of these avc messages, and if you set it up to email, you would be getting emails about it.

So in conclusion, while it is regrettable that any piece of software has a vulnerability, and we work hard to fix them when we find them, it's good to know that SELinux is there to lessen the impact.

SE Linux and vulnerabilities

(Anonymous)

2007-05-19 07:05 am (UTC)

I think demonstrating how SE Linux can mitigate existing vulnerabilities is an excellent way to promote the use of SE Linux. It would be great if RedHat could play up the advantage to SE Linux users (and thus the superiority of RHEL as it seems to be the only one shipping with SE Linux enabled) in their security vulnerability alerts or something. I often use the example of the old ssh exploit to explain how SE Linux would have helped because it allows me to explain how least priviledge works, transitions, etc.

Tracy Reed
treed@tracyreed.org

No HTML allowed in subject

  
 
   
 

(will be screened)

You are viewing danwalsh