On 02/02/2017 11:46 AM, Leonard den Ottolander wrote:
That memory leak can be used to cause the heap and the stack to run in to each other, and that flaw has previously been combined with bugs in glibc to produce an exploit. The glibc bug is now fixed, but there is still a risk that collision could be exploitable in combination with other, as yet undiscovered bugs.
Yes. I understand perfectly well how this works, which is why I am so concerned.
I apologize if my intent was unclear. I was providing you with the text that you should use in your bug report. I am not explaining the problem to you, I am showing you a clear way to explain the problem in the bug report. You should use the appropriate parts of the text I provided, and basically nothing else.
And that is exactly why I also want to fix those memory leaks in pkcheck.c. There might not be a known exploit for pkcheck.c but the vector ("heap spraying" because of a memory leak) is the same.
No. Stop. Drop the issue of pkcheck.c entirely. No one will listen to you as long as you continue to refer to that file. Completely stop talking about it.
pkcheck.c executes entirely in the security context of the user's own session. It does not have any security rights that the user does not have. The user may be able to cause it to crash or execute code, but it cannot execute any code that the user wouldn't have been able to call on their own, directly. It is not a security flaw, because it *doesn't change the user's security context.* Your bugs will continue to be closed with WONTFIX until you understand that.
I am honestly trying to help you. I would like to see the issue with pkexec.c fixed. But you have to listen to this point: causing a program to crash isn't a security flaw unless that program operates in a different security context than your own. Crashing your own programs, within your own security context, isn't a security flaw. It's just a bug. Stop chasing the bug, and focus on the potential security flaw in psexec.c