Re: Serious attack vector on pkcheck ignored by Red Hat

[Leonard den Ottolander <leonard@xxxxxxxxxxxxxxxxx>]

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


_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos