CentOS - Feb 2017 - Serious attack vector on pkcheck ignored by Red Hat

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.
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://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 one more time. "Heap spraying" in itself is a very
powerful attack vector. It will simplify any attack on any binary that
is affected. Read the article and weep. (The ridiculous value of that
kernel parameter is making matters even worse, but I understand I'll
have to take up that issue elsewhere.) 

We do not need the privilege escalation in the binary. The vector will
make any attack way easier, including a potential privilege escalation.
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.

But I agree that to get the more serious issue fixed I should stop
talking about pkcheck.c in those bug reports ;) .

Thanks for your input.

Regards,
Leonard.

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

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 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 pkcheck to call system(/bin/sh), all 
they've done is launched a shell that runs under their own uid.  They 
don't have to attack pkcheck to do that, they can just run /bin/sh directly.

Escalation *requires* attacking a program in a security context other 
than your own.  If you have a SUID binary, you can initiate the 
execution of code which operates in the security context of the user to 
which it is SUID.  If you can cause it to execute arbitrary code, then 
you've escalated your privileges by gaining a new security context.  You 
might also escalate privileges by attacking a daemon that runs in a 
different security context.  If you can cause it to execute arbitrary 
code, you have your security rights plus whatever rights the daemon 
has.  That's an escalation.  Executing new code in your own security 
context is not an escalation.  You haven't gained anything new.  You've 
just taken a complex path to execute code that you were already allowed 
to execute.  Does that make sense?

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 heap to his liking and thus
call whatever function he likes, including the one that will cause the
root exploit.

So even though the heap spraying is not an attack in itself it is a
serious "crow bar" i.e. attack vector.

If you read the article carefully the author makes no claims that the
setuid on the binary is a necessity. He clearly states he is "giving
himself a break" by using a setuid binary.

Regards,
Leonard.

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