CentOS - Feb 2017 - 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. 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 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 escalation."  
But that's not true.  The author used pkexec *because* it's SUID root.  
Lots of programs can be made to crash due to memory errors.  Those are 
bugs, but it's only exploitable if you can cause a program that has 
rights other than your own to execute code on your behalf.  If you cause 
a program with your own rights to execute code, you're just executing 
code via a complicated path.  It's not a security flaw because you have 
the rights to execute the same code directly, rather than through a 
memory handling flaw.

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 fixed upstream. (Check references
I provided.)

Two similar memory leaks exist in pkcheck.c, for which I also provided
patches. Even though these might not be so easily exploitable the memory
leaks in themselves allow a local attacker to "spray the heap", which
makes it easier for him to leverage an attack. You do not want to allow
an attacker to have such potent tools readily available.

Memory leaks are always bad, but these are seriously bad because they
are attacker controlled.

Regards,
Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research