search for: pkexec

...onard 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 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 article is *directly* exploitable and has been fix...

...rote: > I?m with Gordon: someone certainly should fix this problem for its own sake, but don?t try to strong-arm Red Hat into doing it 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.

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 mentioned, which is probably why yo...

...s beyond my control where patches are listed in the Red Hat bugzilla pages. I don't think the Red Hat employee involved should have a hard time finding it in my report. > Open a new bug report and focus on this patch, exclusively: > https://cgit.freedesktop.org/polkit/commit/src/programs/pkexec.c?id=6c992bc8aefa195a41eaa41c07f46f17de18e25c > > The upstream developer has disallowed multiple --user specifications in > order to close a memory leak. Yes. This seems to be a better solution than the one I came up with initially and which you mention below, because multiple invocatio...

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

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 exploitable binary so he does not have to add a privilege es...

Twice I've done a fresh install of a "Development" machine. In both cases pkexec as a normal user always returns "Error executing command as another user: No authentication agent was found." This keeps me from getting a root command line and prevents yumex from starting from the launcher. I've googled and found nothing accept some references to installing virtua...

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

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

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

...visory 2017:0392 > > Upstream details at : https://rhn.redhat.com/errata/RHBA-2017-0392.html > 33395736c057583471a3e8d3554adb014d0d4cd167aa03bad5099c02faad1d38 polkit-0.112-11.el7_3.src.rpm Note that this update fixes neither the memory leak in the options parsing of the setuid binary pkexec, nor does it fix the memory leaks in pkcheck. https://googleprojectzero.blogspot.nl/2014/08/the-poisoned-nul-byte-2014-edition.html https://bugs.freedesktop.org/show_bug.cgi?id=99626 https://bugzilla.redhat.com/show_bug.cgi?id=1418278 https://bugzilla.redhat.com/show_bug.cgi?id=1418287 https://bug...

...zen. I just looked this time, before I did an init 3/init 5, and you can't click on anything... except when I click on the uppermost right, and then I see wired, network and it flashes, over and over. I finally restarted X. Now, in the logs, I see a bunch of Jul 26 11:01:51 <workstation> pkexec[29723]: <username>: Executing command [USER=root] [TTY=unknown] [CWD=/home/<username>] [COMMAND=/usr/libexec/gsd-backlight-helper --set-brightness 89] What little I can find sounds as though acpi_als is for a device that's checking the ambient light... NOT for a real monitor on a w...

CentOS Errata and Bugfix Advisory 2017:0392 Upstream details at : https://rhn.redhat.com/errata/RHBA-2017-0392.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 426b0df04652f9936e703dc74a62cdc6b88ddd6e79fe705fcfabbc93469384f7 polkit-0.112-11.el7_3.i686.rpm

CentOS Errata and Bugfix Advisory 2017:0392 Upstream details at : https://rhn.redhat.com/errata/RHBA-2017-0392.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 426b0df04652f9936e703dc74a62cdc6b88ddd6e79fe705fcfabbc93469384f7 polkit-0.112-11.el7_3.i686.rpm

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

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