similar to: Serious attack vector on pkcheck ignored by Red Hat

On Thu, 2017-02-02 at 06:40 -0800, 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.

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

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

On Thu, 2017-02-02 at 10:39 -0800, Gordon Messmer wrote: > It took me a while to find the patch that you mentioned, which is > probably why your bugs are being disregarded. It is 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

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

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.

Hello Warren, On Thu, 2017-02-09 at 15:27 -0700, Warren Young wrote: > So you?ve now sprayed the heap on this system, but you can?t upload > anything else to it because noexec, so?now what? What has our > nefarious attacker gained? So the heap is set with data provided by the (local) attacker who could initialize it to his liking using either of the two memory leaks in the options

On 02/09/2017 02:27 PM, Warren Young wrote: > 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

Hello Johnny, On Wed, 2017-02-15 at 09:47 -0600, Johnny Hughes wrote: > 2. They already have shell access on the machine in question and they > can already run anything in that shell that they can run via what you > are pointing out. No, assuming noexec /home mounts all they can run is system binaries. > 3. If they have access to a zeroday issue that give them root .. they >

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

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

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

On 02/15/2017 08:22 AM, Chris Adams wrote: > noexec is not that big of a protection. On a normal CentOS system, you > almost certainly have python installed (as well as likely other > scripting languages such as perl), and they can be used to do just about > anything compiled code can do. Exactly. Since python is required by yum (and gettext, and systemd-sysv), it's nearly

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

On Fri, 2017-03-03 at 13:26 +0000, Johnny Hughes wrote: > CentOS Errata and Bugfix Advisory 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

On 02/15/2017 09:37 AM, Leonard den Ottolander wrote: > Hello Warren, > > On Thu, 2017-02-09 at 15:27 -0700, Warren Young wrote: >> So you?ve now sprayed the heap on this system, but you can?t upload >> anything else to it because noexec, so?now what? What has our >> nefarious attacker gained? > > So the heap is set with data provided by the (local) attacker who

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

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 ? -- john r pierce, recycling bits in santa cruz

Johnny Hughes wrote: > On 02/15/2017 09:37 AM, Leonard den Ottolander wrote: >> On Thu, 2017-02-09 at 15:27 -0700, Warren Young wrote: >>> So you?ve now sprayed the heap on this system, but you can?t upload anything else to it because noexec, so?now what? What has our nefarious attacker gained? >> >> So the heap is set with data provided by the (local) attacker who

On Feb 9, 2017, at 2:03 PM, Leonard den Ottolander <leonard at den.ottolander.nl> wrote: > > 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. There