On Feb 9, 2017, at 2:39 PM, Leonard den Ottolander leonard@den.ottolander.nl wrote:
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
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.
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?
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”.
That sounds like an esthetic argument, not a logical argument. “Heap spraying” sounds scary, so let’s fix it!
What I want to know is, what can you *do* with a sprayed heap caused by an unprivileged executable?
Realize that as soon as a second executable starts, it doesn’t see the sprayed heap. The kernel zeroes all reassigned memory pages. Your attack must therefore work within the pkcheck process, while that sprayed heap is still active.
- There’s no such thing as SUID libraries.
I never argued there are.
I threw that idea out in an effort to follow the Principle of Charity. (https://goo.gl/uwS4UE) I wasn’t required to provide the idea in the first place; the burden of proof was on you, and remains there, even though you’ve rejected my attempt to provide you with such an idea.
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.
Now you’re just moving the goalposts. The nature of the vulnerability does not change just because we call it a “kernel” instead of a “library”. A vulnerable kernel is a vulnerable kernel, and does not require that we fix all the other problems on the system in order to fix the kernel.
I’m with Gordon: someone certainly should fix this problem for its own sake, but don’t try to strong-arm Red Hat into doing it for you because Security.
Way too many bad things are done Because Security.