On Thu, 2017-02-02 at 12:18 -0800, Gordon Messmer wrote:
> 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.
Ok. No offense was taken :-) . But, seeing that the upstream and
midstream developer are the same I think he understands the issue quite
well himself. (That is, apart from the fact that the binary needs not to
be setuid for this to be worrisome ;) .
> 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.
Oops, too late. I did mention it as an FYI in the new reports. But the
subject is about pkexec.c only.
https://bugzilla.redhat.com/show_bug.cgi?id=1418824
https://bugzilla.redhat.com/show_bug.cgi?id=1418825
> 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.
I'll try this one more time. "Heap spraying" in itself is a very
powerful attack vector. It will simplify any attack on any binary that
is affected. Read the article and weep. (The ridiculous value of that
kernel parameter is making matters even worse, but I understand I'll
have to take up that issue elsewhere.)
We do not need the privilege escalation in the binary. The vector will
make any attack way easier, including a potential privilege escalation.
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.
But I agree that to get the more serious issue fixed I should stop
talking about pkcheck.c in those bug reports ;) .
Thanks for your input.
Regards,
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
