[CentOS] Serious attack vector on pkcheck ignored by Red Hat

Thu Feb 2 21:40:43 UTC 2017
Gordon Messmer <gordon.messmer at gmail.com>

On 02/02/2017 12:37 PM, Leonard den Ottolander wrote:
> So by continuing to have these memory leaks in the binary you are making
> it easier for a malevolent local user to mount an attack that might
> cause the "desired" privilege escalation.


I'm really struggling to explain this more simply and clearly. Privilege 
escalation means that the attacker gains a privilege they do not start 
with.  Right?  Escalation means that you end with more than you started 
with.

If a local user runs pkcheck in a manner that triggers the flaw, they 
might be able to cause it to execute some code.  In the blog you cited, 
they were able to call chroot() and then system(/bin/sh).  But your 
hypothetical malicious local user doesn't have root privs, so they can't 
call chroot().  And if they force pkcheck to call system(/bin/sh), all 
they've done is launched a shell that runs under their own uid.  They 
don't have to attack pkcheck to do that, they can just run /bin/sh directly.

Escalation *requires* attacking a program in a security context other 
than your own.  If you have a SUID binary, you can initiate the 
execution of code which operates in the security context of the user to 
which it is SUID.  If you can cause it to execute arbitrary code, then 
you've escalated your privileges by gaining a new security context.  You 
might also escalate privileges by attacking a daemon that runs in a 
different security context.  If you can cause it to execute arbitrary 
code, you have your security rights plus whatever rights the daemon 
has.  That's an escalation.  Executing new code in your own security 
context is not an escalation.  You haven't gained anything new.  You've 
just taken a complex path to execute code that you were already allowed 
to execute.  Does that make sense?