Re: Serious attack vector on pkcheck ignored by Red Hat

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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@xxxxxxxxxx
> 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
++++++++++++++++++++++++++++++++++++++++
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos




[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux