[CentOS] Serious attack vector on pkcheck ignored by Red Hat
Gordon Messmer
gordon.messmer at gmail.com
Thu Feb 2 21:40:43 UTC 2017
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?
More information about the CentOS
mailing list