search for: pkcheck

...for you because Security. > > Way too many bad things are done Because Security. My larger concern is that there *does* seem to be a security issue with pkexec that has at least two very simple fixes, and that issue isn't being addressed because of the noise involved in arguing about pkcheck. There's no security problem in pkcheck, and all of the time spent insisting that there is serves to further delay fixing pkexec.

..., John R Pierce wrote: > On 2/2/2017 6:22 AM, Leonard den Ottolander wrote: > > However, the fact that the binary in the example is setuid is orthogonal > > to the fact that heap spraying is a very serious attack vector. > > without privilege escalation, what does it attack ? pkcheck might not be directly vulnerable. However, pkexec is. Closing these bugs because pkcheck might not be directly vulnerable also stops pkexec from being fixed. And pkexec clearly is vulnerable. Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research

On Thu, 2017-02-02 at 13:40 -0800, Gordon Messmer wrote: > Escalation *requires* attacking a program in a security context other > than your own. Not necessarily. Suppose the adversary is aware of a root exploit/privilege escalation in a random library. Then the heap spraying allows this attacker to easily trigger this exploit because he is able to initialize the entire contents of the

Hello Warren, On Thu, 2017-02-09 at 14:22 -0700, Warren Young wrote: > There are two serious problems with this argument: > > 1. Give me a scenario where this attacker can execute *only* pkcheck > in order to exploit this hypothetical library?s flaw, but where the > attacker cannot simply provide their own binary to do the same > exploit. Short of something insane like exposing pkcheck via CGI over > HTTP, I don?t see how a flaw in pkcheck gives you something here that > yo...

...e 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. 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. That "heap spraying" will make it easier for an attacker to leverage any attack including a privilege escalation so it is worrisome even if the binary itsel...

...ize it to his liking using either of the two memory leaks in the options parsing. The heap, that is entirely under the control of the attacker, now contains a call to a library with parameters such that it invokes a zero day kernel escalation privilege exploit. And now the exploit will run because pkcheck allowed the attacker to initialize its entire heap via the command line. Had the two memory leaks in the pkcheck options parsing been fixed the attacker should have looked for another path to leverage his zero day. So the mere fact that an untrusted user is able to massage the heap of a binary (p...

On Thu, 2017-02-02 at 07:16 -0800, Gordon Messmer wrote: > On 02/02/2017 06:51 AM, Leonard den Ottolander wrote: > > pkcheck might not be directly vulnerable. However, pkexec is. > > > If that's so, why are you supplying patches to pkcheck rather than > fixing pkexec? The patch has a fix for three memory leaks. One memory leak that allows heap spraying in pkexec.c that according to the aforementioned...

...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....

...othing 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://bu...

Based on an article that was mentioned on this list https://googleprojectzero.blogspot.nl/2014/08/the-poisoned-nul-byte-2014-edition.html I found two attacker controlled memory leaks in the option parsing of pkcheck.c. These memory leaks allow a local attacker the ability to "spray the heap", i.e. initialize large parts of the heap before launching his attack. The original attack uses a setuid binary, because the author "is giving himself a break". However, the fact that the binary in the...

...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...

...program in a security context other >> than your own. > > Not necessarily. Suppose the adversary is aware of a root > exploit/privilege escalation in a random library. There are two serious problems with this argument: 1. Give me a scenario where this attacker can execute *only* pkcheck in order to exploit this hypothetical library?s flaw, but where the attacker cannot simply provide their own binary to do the same exploit. Short of something insane like exposing pkcheck via CGI over HTTP, I don?t see how a flaw in pkcheck gives you something here that you don?t already have. A...

On 2/9/2017 2:40 PM, Gordon Messmer wrote: > > My larger concern is that there *does* seem to be a security issue > with pkexec that has at least two very simple fixes, and that issue > isn't being addressed because of the noise involved in arguing about > pkcheck. There's no security problem in pkcheck, and all of the time > spent insisting that there is serves to further delay fixing pkexec. you realize noone on this email list has anything to do with the source code for this pkcheck thing? CentOS uses the code exactly as is that Red Hat rel...

...her of the two memory leaks in the > options parsing. > > The heap, that is entirely under the control of the attacker, now > contains a call to a library with parameters such that it invokes a zero > day kernel escalation privilege exploit. And now the exploit will run > because pkcheck allowed the attacker to initialize its entire heap via > the command line. > > Had the two memory leaks in the pkcheck options parsing been fixed the > attacker should have looked for another path to leverage his zero day. > > So the mere fact that an untrusted user is able to m...

...choose. You *absolutely* do not need a heap spraying attack in order to make arbitrary library or kernel calls. Leonard, man... you've got let this go. Users with shell access already have fairly broad permission to execute arbitrary code on the system they log in to. The memory leak in pkcheck is *not* a security issue. It's just a bug. *Everyone* is trying to tell you this, including the maintainers of CentOS, and (in your original bug report) the maintainers of RHEL. The security bug you've used as a foundation for all of this was built on a SUID binary, which pkcheck is...

On 02/02/2017 06:51 AM, Leonard den Ottolander wrote: > pkcheck might not be directly vulnerable. However, pkexec is. If that's so, why are you supplying patches to pkcheck rather than fixing pkexec? If your bug report, you said, "The author clearly states that in his example exploit he gives himself a break, ... choosing a more easily exploitabl...

On 02/02/2017 07:35 AM, Leonard den Ottolander wrote: >> If that's so, why are you supplying patches to pkcheck rather than >> fixing pkexec? > The patch has a fix for three memory leaks. One memory leak that allows > heap spraying in pkexec.c that according to the aforementioned article > is*directly* exploitable and has been fixed upstream. It took me a while to find the patch that you m...

...Feb 9, 2017, at 2:39 PM, Leonard den Ottolander <leonard at den.ottolander.nl> wrote: > > On Thu, 2017-02-09 at 14:22 -0700, Warren Young wrote: >> There are two serious problems with this argument: >> >> 1. Give me a scenario where this attacker can execute *only* pkcheck > > On many systems local users cannot execute their own uploaded binaries > (noexec mounts). 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 b...

...ing using either of the two memory leaks in the options parsing. >> >> The heap, that is entirely under the control of the attacker, now contains a call to a library with parameters such that it invokes a zero day kernel escalation privilege exploit. And now the exploit will run because pkcheck allowed the attacker to initialize its entire heap via the command line. <snip> I've skipped most of this thread, but went through this post, and excuse me if this sounds like a stupid question... but when the attacker runs their job, isn't it *THEIR* heap, one allocated for this PID,...

...ive them root .. they > can just use that via their shell that they already have (that you gave > them, which they are using) to get root .. they therefore don't need to > use this issue at all. No, assuming noexec /home mounts all they have to leverage a zero day are system binaries. pkcheck to the rescue. Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research