Proof is in the pudding

[Douglas Brown]

Hi all,

You may have seen this vulnerability talked about recently:
http://arstechnica.com/security/2013/05/critical-linux-vulnerability-impe...

After a long time of evangelising about SELinux to my sceptical colleagues, this seemed
like the perfect opportunity to test it.

We tried the exploit with SELinux in permissive mode and it worked then in enforcing and
SELinux prevented it! Not that I'm surprised, but it's nice to have a real-world
exploit to demonstrate.

Cheers,
Doug

[Tristan Santore]

On 17/05/13 01:03, Douglas Brown wrote:
>  Hi all,
>
>  You may have seen this vulnerability talked about recently:
>
> http://arstechnica.com/security/2013/05/critical-linux-vulnerability-impe...
>
>  After a long time of evangelising about SELinux to my sceptical
>  colleagues, this seemed like the perfect opportunity to test it.
>
>  We tried the exploit with SELinux in permissive mode and it worked then
>  in enforcing and SELinux prevented it! Not that I'm surprised, but it's
>  nice to have a real-world exploit to demonstrate.
>
>  Cheers,
>  Doug
>
>
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
That is a misleading statement to make. We tested this in enforcing 
mode, and it worked. However, there is Supervisor Mode Execution 
Protection (SMEP) support on some Intel CPU, maybe that prevented it.
Weird though that you stated that it was prevented from exploiting with 
selinux enabled.

So, the question is, is your normal user confined ?
What cpu model do you have  ? And did you test on different machines/cpu ?

It should also be stated, that in the targeted policy model, users are 
not confined.

Regards,
Tristan

-- 
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile [phone]
Tristan.Santore(a)internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org

[Douglas Brown]

On 17/05/13 10:21 AM, "Tristan Santore"
<tristan.santore(a)internexusconnect.net&gt; wrote:

> On 17/05/13 01:03, Douglas Brown wrote:
> > Hi all,
> >
> > You may have seen this vulnerability talked about recently:
> > 
> >http://arstechnica.com/security/2013/05/critical-linux-vulnerability-impe
> >rils-users-even-after-silent-fix/
> >
> > After a long time of evangelising about SELinux to my sceptical
> > colleagues, this seemed like the perfect opportunity to test it.
> >
> > We tried the exploit with SELinux in permissive mode and it worked then
> > in enforcing and SELinux prevented it! Not that I'm surprised, but it's
> > nice to have a real-world exploit to demonstrate.
> >
> > Cheers,
> > Doug
> >
> >
> > --
> > selinux mailing list
> > selinux(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
> >
> That is a misleading statement to make. We tested this in enforcing
> mode, and it worked. However, there is Supervisor Mode Execution
> Protection (SMEP) support on some Intel CPU, maybe that prevented it.
> Weird though that you stated that it was prevented from exploiting with
> selinux enabled.
>
> So, the question is, is your normal user confined ? 
Yep, the pre-defined user_u:user_r...

> What cpu model do you have  ? And did you test on different
> machines/cpu ? 
No sure; the machine is virtual and on an ESX cluster so it may have
vMotioned already...

> It should also be stated, that in the targeted policy model, users
> are
> not confined. 
I'm talking about SELinux proving its worth in general as a useful
technology that shouldn't just be 'turned off' at the first opportunity.

Cheers,
Doug

[Tristan Santore]

On 17/05/13 01:03, Douglas Brown wrote:
>  Hi all,
>
>  You may have seen this vulnerability talked about recently:
>
> http://arstechnica.com/security/2013/05/critical-linux-vulnerability-impe...
>
>  After a long time of evangelising about SELinux to my sceptical
>  colleagues, this seemed like the perfect opportunity to test it.
>
>  We tried the exploit with SELinux in permissive mode and it worked then
>  in enforcing and SELinux prevented it! Not that I'm surprised, but it's
>  nice to have a real-world exploit to demonstrate.
>
>  Cheers,
>  Doug
>
>
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
Actually, it is quite irrelevant, if the user is confined, because the 
exploit can be modified to disable selinux, giving full access to the 
system. Fact is, this exploit is quite nasty in that respect, as you can 
pretty much modify anything.
So, in other words, it just makes the attackers life a tiny bit harder, 
unless she is a script kiddie.

Regards,
Tristan

-- 
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile [phone]
Tristan.Santore(a)internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org

[Douglas Brown]

On 17/05/13 10:29 AM, "Tristan Santore"
<tristan.santore(a)internexusconnect.net&gt; wrote:

> On 17/05/13 01:03, Douglas Brown wrote:
> > Hi all,
> >
> > You may have seen this vulnerability talked about recently:
> > 
> >http://arstechnica.com/security/2013/05/critical-linux-vulnerability-impe
> >rils-users-even-after-silent-fix/
> >
> > After a long time of evangelising about SELinux to my sceptical
> > colleagues, this seemed like the perfect opportunity to test it.
> >
> > We tried the exploit with SELinux in permissive mode and it worked then
> > in enforcing and SELinux prevented it! Not that I'm surprised, but it's
> > nice to have a real-world exploit to demonstrate.
> >
> > Cheers,
> > Doug 
> Actually, it is quite irrelevant, if the user is confined, because
> the
> exploit can be modified to disable selinux, giving full access to the
> system. Fact is, this exploit is quite nasty in that respect, as you can
> pretty much modify anything.
> So, in other words, it just makes the attackers life a tiny bit harder,
> unless she is a script kiddie. 
If you think this is the case, please demonstrate.

Cheers,
Doug

[Tristan Santore]

On 17/05/13 01:29, Tristan Santore wrote:
>  On 17/05/13 01:03, Douglas Brown wrote:
> > Hi all,
> >
> > You may have seen this vulnerability talked about recently:
> >
> http://arstechnica.com/security/2013/05/critical-linux-vulnerability-impe...
> >
> >
> > After a long time of evangelising about SELinux to my sceptical
> > colleagues, this seemed like the perfect opportunity to test it.
> >
> > We tried the exploit with SELinux in permissive mode and it worked then
> > in enforcing and SELinux prevented it! Not that I'm surprised, but it's
> > nice to have a real-world exploit to demonstrate.
> >
> > Cheers,
> > Doug
> >
> >
> > --
> > selinux mailing list
> > selinux(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
> >
>  Actually, it is quite irrelevant, if the user is confined, because the
>  exploit can be modified to disable selinux, giving full access to the
>  system. Fact is, this exploit is quite nasty in that respect, as you can
>  pretty much modify anything.
>  So, in other words, it just makes the attackers life a tiny bit harder,
>  unless she is a script kiddie.
>
>  Regards,
>  Tristan
>  
Looks like I hit the wrong reply button, so I will just say it again. As 
the exploit gives access to ring0, there is nothing you cannot do with 
minor code changes to the exploit.

Yes, of course one should not turn selinux off, as it is a mitigation 
step and will make an attackers life a lot harder, if not impossible.
However, when you hit kernel exploits such as semtex, there is not much 
you can do, but make sure you update the kernel and generally 
prevent/fix other attack vectors by updating all packages.

The sysctl line below will mitigate the unmodified attack vector.

sysctl kernel.perf_event_paranoid=2

However, the author of the exploit would just rewrite the code to adapt 
to this mitigation attempt.

There is now an update available:
https://rhn.redhat.com/errata/RHSA-2013-0830.html

Also, I have just received an email, which confirms the fix also has 
been pushed to CEntOS mirrors.

So, this issue is now rectified across the board. If you want to play 
with it and modify semtex for your own research purposes, please feel free.

Regards,
Tristan

-- 
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile [phone]
Tristan.Santore(a)internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org

[Trevor Hemsley]

On 17/05/13 01:03, Douglas Brown wrote:
>  Hi all,
>  
>  You may have seen this vulnerability talked about
>  recently:
> http://arstechnica.com/security/2013/05/critical-linux-vulnerability-impe...
>  
>  After a long time of evangelising about SELinux to my sceptical
>  colleagues, this seemed like the perfect opportunity to test it.
>  
>  We tried the exploit with SELinux in permissive mode and it worked then
>  in enforcing and SELinux prevented it! Not that I'm surprised, but it's
>  nice to have a real-world exploit to demonstrate. 
Unfortunately, whatever you tested was not this.

$ ls -la sem*
-rwxrwxr-x. 1 trevor trevor 10007 May 14 13:39 semtex
-rw-rw-r--. 1 trevor trevor  2488 May 14 13:39 semtex.c
$ getenforce
Enforcing
$ uname -a
Linux hostname 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 19:29:00 UTC
2013 x86_64 x86_64 x86_64 GNU/Linux
$ ./semtex
2.6.37-3.x x86_64
sd(a)fucksheep.org 2010
-sh-4.1#

Sorry.

Trevor

[Tristan Santore]

On 17/05/13 02:32, Trevor Hemsley wrote:
>  On 17/05/13 01:03, Douglas Brown wrote:
> > Hi all,
> >
> > You may have seen this vulnerability talked about
> > recently:
> http://arstechnica.com/security/2013/05/critical-linux-vulnerability-impe...
> >
> > After a long time of evangelising about SELinux to my sceptical
> > colleagues, this seemed like the perfect opportunity to test it.
> >
> > We tried the exploit with SELinux in permissive mode and it worked then
> > in enforcing and SELinux prevented it! Not that I'm surprised, but it's
> > nice to have a real-world exploit to demonstrate.
>
>  Unfortunately, whatever you tested was not this.
>
>  $ ls -la sem*
>  -rwxrwxr-x. 1 trevor trevor 10007 May 14 13:39 semtex
>  -rw-rw-r--. 1 trevor trevor  2488 May 14 13:39 semtex.c
>  $ getenforce
>  Enforcing
>  $ uname -a
>  Linux hostname 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 19:29:00 UTC
>  2013 x86_64 x86_64 x86_64 GNU/Linux
>  $ ./semtex
>  2.6.37-3.x x86_64
>  sd(a)fucksheep.org 2010
>  -sh-4.1#
>
>  Sorry.
>
>  Trevor
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux
>  
Trevor,
Are you running targeted policy ? If so, the normal users are 
unconfined_u, that is unconfined_u:object_r:user_home_t:s0.

If you make the user confined, you get something like this, for example:
2.6.37-3.x x86_64
sd(a)fucksheep.org 2010
-sh: /home/$USER/.profile: Permission denied
-sh-4.1# ^C
-sh-4.1# kill -9 19457
-sh: kill: (19457) - Operation not permitted
-sh-4.1# init 6
-sh: init: command not found
-sh-4.1# su
-sh: su: command not found

But as I said, you could modify the exploit to turn of selinux.

So, SElinux kind of mitigates the attack, but it is not a fix, just an 
obstacle.

SElinux can never really be a system to implement a 100% secure system, 
like many other technologies that do the same.
The golden rule is: There is no 100% secure system.

However, I think we should all be grateful, that linux has various 
mitigation technologies available to it.

Regards,
Tristan

-- 
Tristan Santore BSc MBCS
TS4523-RIPE
Network and Infrastructure Operations
InterNexusConnect
Mobile [phone]
Tristan.Santore(a)internexusconnect.net

Former Thawte Notary
(Please note: Thawte has closed its WoT programme down,
and I am therefore no longer able to accredit trust)

For Fedora related issues, please email me at:
TSantore(a)fedoraproject.org

[yersinia]

All the above was already discussed in the relevant bugzilla entry.
and some part of the discussion was written by myself also.and iirc
something similar already happened some years ago. Not a selinux, or
apparmor, problem however.

Best

2013/5/17, Tristan Santore <tristan.santore(a)internexusconnect.net&gt;:
>  On 17/05/13 02:32, Trevor Hemsley wrote:
> > On 17/05/13 01:03, Douglas Brown wrote:
> >> Hi all,
> >>
> >> You may have seen this vulnerability talked about
> >> recently:
> >>
> http://arstechnica.com/security/2013/05/critical-linux-vulnerability-impe...
> >>
> >> After a long time of evangelising about SELinux to my sceptical
> >> colleagues, this seemed like the perfect opportunity to test it.
> >>
> >> We tried the exploit with SELinux in permissive mode and it worked then
> >> in enforcing and SELinux prevented it! Not that I'm surprised, but it's
> >> nice to have a real-world exploit to demonstrate.
> >
> > Unfortunately, whatever you tested was not this.
> >
> > $ ls -la sem*
> > -rwxrwxr-x. 1 trevor trevor 10007 May 14 13:39 semtex
> > -rw-rw-r--. 1 trevor trevor  2488 May 14 13:39 semtex.c
> > $ getenforce
> > Enforcing
> > $ uname -a
> > Linux hostname 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 19:29:00 UTC
> > 2013 x86_64 x86_64 x86_64 GNU/Linux
> > $ ./semtex
> > 2.6.37-3.x x86_64
> > sd(a)fucksheep.org 2010
> > -sh-4.1#
> >
> > Sorry.
> >
> > Trevor
> > --
> > selinux mailing list
> > selinux(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
> >
>  Trevor,
>  Are you running targeted policy ? If so, the normal users are
>  unconfined_u, that is unconfined_u:object_r:user_home_t:s0.
>
>  If you make the user confined, you get something like this, for example:
>  2.6.37-3.x x86_64
>  sd(a)fucksheep.org 2010
>  -sh: /home/$USER/.profile: Permission denied
>  -sh-4.1# ^C
>  -sh-4.1# kill -9 19457
>  -sh: kill: (19457) - Operation not permitted
>  -sh-4.1# init 6
>  -sh: init: command not found
>  -sh-4.1# su
>  -sh: su: command not found
>
>  But as I said, you could modify the exploit to turn of selinux.
>
>  So, SElinux kind of mitigates the attack, but it is not a fix, just an
>  obstacle.
>
>  SElinux can never really be a system to implement a 100% secure system,
>  like many other technologies that do the same.
>  The golden rule is: There is no 100% secure system.
>
>  However, I think we should all be grateful, that linux has various
>  mitigation technologies available to it.
>
>  Regards,
>  Tristan
>
>  --
>  Tristan Santore BSc MBCS
>  TS4523-RIPE
>  Network and Infrastructure Operations
>  InterNexusConnect
>  Mobile [phone]
>  Tristan.Santore(a)internexusconnect.net
>
>  Former Thawte Notary
>  (Please note: Thawte has closed its WoT programme down,
>  and I am therefore no longer able to accredit trust)
>
>  For Fedora related issues, please email me at:
>  TSantore(a)fedoraproject.org
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
-- 
Inviato dal mio dispositivo mobile