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