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?
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx https://lists.centos.org/mailman/listinfo/centos
