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

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

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

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

On 02/02/2017 12:37 PM, Leonard den Ottolander wrote: > 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. I'm really struggling to explain this more simply and clearly. Privilege escalation means that the attacker gains a privilege they

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

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

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

Once upon a time, Leonard den Ottolander <leonard at den.ottolander.nl> said: > 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

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

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

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 Wed, February 15, 2017 10:22 am, Chris Adams wrote: > Once upon a time, Leonard den Ottolander <leonard at den.ottolander.nl> said: >> 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