Hello Warren,
On Thu, 2017-02-09 at 14:22 -0700, Warren Young wrote:
There are two serious problems with this argument:
- 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".
- 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.