<div dir="ltr"><div><div><div><div><div>Ok...so going on what you first posted:<br><br>">> Given a command prompt, download this exploit, compile it, run it... and<br>
>> you suddenly have root. What is interesting about this is, as soon as you<br>
>> have root, you can disable SELinux."<br><br></div>So you're saying that this exploit allows an attacker to not only obtain a root shell but to also disable SELinux even if strict or MLS policy is being enforced? Otherwise, with the Targeted policy, this is nothing new.<br>
<br></div><div>Been quite a while since I dug into SELinux, hope the memory is still good here...<br></div><div><br></div>While you are correct, dependent upon the policy, SELinux can prevent actions by root based on MAC, IIRC this requires MLS/MCS to be enabled and the system completely labeled/relabeled as such. With the default Targeted policy, root can both disable SElinux and set it into permissive mode. Again, game over. Now, if you're running MLS/MCS, you may be correct, but for most shops, getting them to run SELinux at all is like pulling teeth. SELinux is not magical, it is nothing more than a MAC implementation. How you configure your SELinux implementation is where the rubber meets the road. For most, this is simply installing RHEL/CentOS with SELinux enforcing default Targeted (if enabled at all). If I can get to a root shell, there is nothing stopping me from disabling SELinux or setting it to permissive when running the Targeted policy. SELinux's value is in preventing an attacker from getting a root shell in the first place by disallowing a process from accessing something outside of what has been defined in policy, once you have a root shell, again, game over (again, unless you're using MLS/MCS).<br>
<br>"MAC provides strong separation of applications that permits the safe
execution of untrustworthy applications. Its ability to limit the
privileges associated with executing processes limits the scope of
potential damage that can result from the exploitation of
vulnerabilities in applications and system services."<br><a href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/chap-Security-Enhanced_Linux-Introduction.html#sect-Security-Enhanced_Linux-Introduction-Benefits_of_running_SELinux">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/chap-Security-Enhanced_Linux-Introduction.html#sect-Security-Enhanced_Linux-Introduction-Benefits_of_running_SELinux</a><br>
<br></div>In this case, the exploit has achieved a root shell; either SELinux was circumvented or what was being exploited was not confined. In either case, SELinux did not prevent the exploit and once root shell is obtained, by design in Targeted, root can disable or change the SELinux configuration from enforcing to permissive.<br>
<br></div>The fact that you get the root shell from this exploit tells me this not interesting from the SELinux perspective, it is only interesting from that perspective if the process exploited was confined by SELinux policy, or root is confined by an MLS/MCS policy once the root shell is achieved.<br>
<br></div>-nd<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 14, 2013 at 1:37 PM, Joshua Kramer <span dir="ltr"><<a href="mailto:joskra42.list@gmail.com" target="_blank">joskra42.list@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">"<span style="font-family:arial,sans-serif;font-size:13px">With the right profiles, a major selling point of SELinux (as "we" use</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">it) is that it's *not* game over just because you got root."</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>
<span style="font-family:arial,sans-serif;font-size:13px">In theory it shouldn't be. Running processes have contexts attached to them; this article I wrote a few years ago explains:</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><a href="http://www.packtpub.com/article/selinux-secured-web-hosting-python-based-web-applications" target="_blank">http://www.packtpub.com/article/selinux-secured-web-hosting-python-based-web-applications</a><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div><br></div><div>Essentially, each running process has a context attached to it. Even if the process elevates to root privilege (i.e. running a SUID executable, having exploit code such as we see here, etc.), the OS sees that the process has a certain context and denies permission for stuff it shouldn't have. In the example I used in the article, a SUID root executable copies /etc/shadow when it is run from a website that has ostensibly been cracked. When SELinux is disabled, this works. When SELinux is enabled, the OS says, "Hey HTTPD, I don't care if you say you're root, you can't touch /etc/shadow!" I never thought to attempt to set /selinux/enforcing to 0 and then attempt that... but I'd hope that the OS would say, "Hey HTTPD, I don't care if you say you're root, you can't touch /selinux/enforcing!"</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 14, 2013 at 1:22 PM, Rick Troth <span dir="ltr"><<a href="mailto:rmt@casita.net" target="_blank">rmt@casita.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Not sure what is interesting about the ability to disable SELinux; you have root, game over.<br>
<br>
With the right profiles, a major selling point of SELinux (as "we" use<br>
it) is that it's *not* game over just because you got root. (There<br>
are other features of SELinux which are more interesting to the NSA<br>
than they are to you and me.)<br>
<br>
I'm not personally a fan, but I'm not using this as an opportunity to<br>
jab at it ... or maybe I am.<br>
<br>
-- R; <><<br>
<br>
<br>
<br>
<br>
On Tue, May 14, 2013 at 1:00 PM, Neal Dias <<a href="mailto:roman@ensecure.org" target="_blank">roman@ensecure.org</a>> wrote:<br>
> Not sure what is interesting about the ability to disable SELinux; you have<br>
> root, game over.<br>
><br>
> RHEL 5 is not affected, RHEL 6 is, updated packages still in-process.<br>
><br>
> <a href="https://access.redhat.com/security/cve/CVE-2013-2094" target="_blank">https://access.redhat.com/security/cve/CVE-2013-2094</a><br>
> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=962792" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=962792</a><br>
<div>><br>
> On Tue, May 14, 2013 at 12:33 PM, Joshua Kramer <<a href="mailto:joskra42.list@gmail.com" target="_blank">joskra42.list@gmail.com</a>><br>
> wrote:<br>
>><br>
</div><div><div>>> Hello,<br>
>><br>
>> I recently saw this:<br>
>><br>
>> <a href="https://www.centos.org/modules/newbb/viewtopic.php?topic_id=42827&forum=59" target="_blank">https://www.centos.org/modules/newbb/viewtopic.php?topic_id=42827&forum=59</a><br>
>><br>
>> Given a command prompt, download this exploit, compile it, run it... and<br>
>> you suddenly have root. What is interesting about this is, as soon as you<br>
>> have root, you can disable SELinux.<br>
>><br>
>> Apparently it can be mitigated using this kernel module:<br>
>><br>
>> <a href="http://elrepo.org/tiki/kmod-tpe" target="_blank">http://elrepo.org/tiki/kmod-tpe</a><br>
>><br>
>> I spun up a test VM and tested this - it works! What would be interesting<br>
>> is doing some investigation to see if SELinux could prevent damage if this<br>
>> code was run from a malicious web app instead of the command prompt.<br>
>><br>
>> Also, I wonder if this works on Scientific Linux and other RHEL<br>
>> derivatives, or RHEL itself?<br>
>><br>
>> Cheers,<br>
>> -JK<br>
>><br>
</div></div><div>>> _______________________________________________<br>
>> colug-432 mailing list<br>
>> <a href="mailto:colug-432@colug.net" target="_blank">colug-432@colug.net</a><br>
>> <a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> colug-432 mailing list<br>
> <a href="mailto:colug-432@colug.net" target="_blank">colug-432@colug.net</a><br>
> <a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
><br>
<br>
<br><span class="HOEnZb"><font color="#888888">
<br>
--<br>
</font></span></div><span class="HOEnZb"><font color="#888888"><span><font color="#888888">-- R; <><<br>
</font></span><div><div>_______________________________________________<br>
colug-432 mailing list<br>
<a href="mailto:colug-432@colug.net" target="_blank">colug-432@colug.net</a><br>
<a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
</div></div></font></span></blockquote></div><br></div>
<br>_______________________________________________<br>
colug-432 mailing list<br>
<a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br>
<a href="http://lists.colug.net/mailman/listinfo/colug-432" target="_blank">http://lists.colug.net/mailman/listinfo/colug-432</a><br>
<br></blockquote></div><br></div>