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@centos.org https://lists.centos.org/mailman/listinfo/centos
