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

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

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 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.
> 
What people are trying to point out to you is:

1.  The 'user' that the 'atacker' can run things as is
themselves .. AND

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.

3.  If they have access to a zeroday issue that give them root .. they
can just use that via their shell that they already have (that you gave
them, which they are using) to get root .. they therefore don't need to
use this issue at all.

===
All of that said, all memory leaks (and any other bugs) should be fixed.

It is just NOT a major security issue.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20170215/195908fe/attachment-0001.sig>

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
> can just use that via their shell that they already have (that you gave
> them, which they are using) to get root .. they therefore don't need to
> use this issue at all.
No, assuming noexec /home mounts all they have to leverage a zero day
are system binaries. pkcheck to the rescue.

Regards,
Leonard.

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