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

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 exposing pkcheck via CGI over
> HTTP, I don?t see how a flaw in pkcheck gives you something here that
> you don?t already have.
On many systems local users cannot execute their own uploaded binaries
(noexec mounts). This would also be true for an adversary entering a
system with a remote "unprivileged" exploit. In that situation pcheck
gives them a "crow bar" they did not have before.
> A vulnerable library is a vulnerable library.  Fix the library, don?t
> invent reasons to fix all the other programs on the system because the
> library is vulnerable.
I would say the modus operandi should be to eliminate all known attack
vectors, including such a powerful one as the described "heap
spraying".
> 2.  There?s no such thing as SUID libraries.
I never argued there are.
>   So, how is this hypothetical library of yours going to gain
> privileges that the executable linked to it does not have?  Point me
> at a CVE where a vulnerable library was used for privilege escalation.
Maybe the example using a library is wrong. But there are other ways to
gain a privilege escalation, kernel bugs for example. Those could be
triggered just as well.

Regards,
Leonard.


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

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
> (noexec mounts). This would also be true for an adversary entering a
> system with a remote "unprivileged" exploit. In that situation
pcheck
> gives them a "crow bar" they did not have before.
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?
>> A vulnerable library is a vulnerable library.  Fix the library, don?t
>> invent reasons to fix all the other programs on the system because the
>> library is vulnerable.
> 
> I would say the modus operandi should be to eliminate all known attack
> vectors, including such a powerful one as the described "heap
spraying?.
That sounds like an esthetic argument, not a logical argument.  ?Heap spraying?
sounds scary, so let?s fix it!

What I want to know is, what can you *do* with a sprayed heap caused by an
unprivileged executable?

Realize that as soon as a second executable starts, it doesn?t see the sprayed
heap.  The kernel zeroes all reassigned memory pages.  Your attack must
therefore work within the pkcheck process, while that sprayed heap is still
active.
>> 2.  There?s no such thing as SUID libraries.
> 
> I never argued there are.
I threw that idea out in an effort to follow the Principle of Charity.
(https://goo.gl/uwS4UE)  I wasn?t required to provide the idea in the first
place; the burden of proof was on you, and remains there, even though you?ve
rejected my attempt to provide you with such an idea.
>> So, how is this hypothetical library of yours going to gain
>> privileges that the executable linked to it does not have?  Point me
>> at a CVE where a vulnerable library was used for privilege escalation.
> 
> Maybe the example using a library is wrong. But there are other ways to
> gain a privilege escalation, kernel bugs for example. Those could be
> triggered just as well.
Now you?re just moving the goalposts.  The nature of the vulnerability does not
change just because we call it a ?kernel? instead of a ?library?.  A vulnerable
kernel is a vulnerable kernel, and does not require that we fix all the other
problems on the system in order to fix the kernel.

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.

On Thu, February 9, 2017 3:39 pm, Leonard den Ottolander
wrote:
> Hello Warren,
Leonard,

I'm sure, the only way you can make your point so that others will listen
to you is by providing an example of bad thing done through the flaw you
have discovered. Which may be:

1. overwriting portions of memory or filesystem belonging to another user
which do not have write permission for this user

2. elevate privileges with the help of the flaw you discovered on sane
patched system, in other words not exploiting some other known
vulnerabilities which on well maintained system do not exists

This is basically the shortest and simplest way to say what others
repeated several times.

I hope, this helps.

Valeri
>
> 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 exposing pkcheck via CGI over
>> HTTP, I don???t see how a flaw in pkcheck gives you something here that
>> you don???t already have.
>
> On many systems local users cannot execute their own uploaded binaries
> (noexec mounts). This would also be true for an adversary entering a
> system with a remote "unprivileged" exploit. In that situation
pcheck
> gives them a "crow bar" they did not have before.
>
>> A vulnerable library is a vulnerable library.  Fix the library, don???t
>> invent reasons to fix all the other programs on the system because the
>> library is vulnerable.
>
> I would say the modus operandi should be to eliminate all known attack
> vectors, including such a powerful one as the described "heap
spraying".
>
>> 2.  There???s no such thing as SUID libraries.
>
> I never argued there are.
>
>>   So, how is this hypothetical library of yours going to gain
>> privileges that the executable linked to it does not have?  Point me
>> at a CVE where a vulnerable library was used for privilege escalation.
>
> Maybe the example using a library is wrong. But there are other ways to
> gain a privilege escalation, kernel bugs for example. Those could be
> triggered just as well.
>
> Regards,
> Leonard.
>
>
> --
> mount -t life -o ro /dev/dna /genetic/research
>
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
>

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

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

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

The heap, that is entirely under the control of the attacker, now
contains a call to a library with parameters such that it invokes a zero
day kernel escalation privilege exploit. And now the exploit will run
because pkcheck allowed the attacker to initialize its entire heap via
the command line.

Had the two memory leaks in the pkcheck options parsing been fixed the
attacker should have looked for another path to leverage his zero day.

So the mere fact that an untrusted user is able to massage the heap of a
binary (pkcheck in this case) to run whatever code he wants is a serious
attack vector and thus those two memory leaks should be fixed. Because
they allow bad people to leverage attacks with much more ease.

Regards,
Leonard.

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