On 02/09/2017 01:03 PM, Leonard den Ottolander wrote:
Not necessarily. Suppose the adversary is aware of a root exploit/privilege escalation in a random library.
There is no such thing as a root exploit in a library. A "root exploit" is one that ends with the attacker executing code as root. That can only be done by attacking an existing process running as root, or by attacking a SUID binary.
There are certainly flaws in libraries that lead to code execution, but the exploit will be described in terms of the entire system that enables privilege escalation, which means the attack will be in the context of a daemon, or a SUID binary.
If you read the article carefully the author makes no claims that the setuid on the binary is a necessity. He clearly states he is "giving himself a break" by using a setuid binary.
No, he doesn't. He gave himself a break by attacking a 32-bit binary instead of the 64 bit one, because causing the heap and the stack to collide in a 64 bit address space is a *lot* more work.
This would also be true for an adversary entering a system with a remote "unprivileged" exploit. In that situation pcheck gives them a "crow bar" they did not have before.
pkcheck doesn't escalate privileges. If they are able to launch a remote exploit which calls pkcheck, they can launch a remote exploit that just calls a shell directly instead. Attacking pkcheck doesn't give them anything extra.
Does it not tell you anything that *everyone* is telling you that there is no security exploit in the ability to cause pkcheck to execute code? It's a bug, but it's not a security flaw.