Leonard den Ottolander
2017-Feb-09 21:03 UTC
[CentOS] Serious attack vector on pkcheck ignored by Red Hat
On Thu, 2017-02-02 at 13:40 -0800, Gordon Messmer wrote:> Escalation *requires* attacking a program in a security context other > than your own.Not necessarily. Suppose the adversary is aware of a root exploit/privilege escalation in a random library. Then the heap spraying allows this attacker to easily trigger this exploit because he is able to initialize the entire contents of the heap to his liking and thus call whatever function he likes, including the one that will cause the root exploit. So even though the heap spraying is not an attack in itself it is a serious "crow bar" i.e. attack vector. If you read the article carefully the author makes no claims that the setuid on the binary is a necessity. He clearly states he is "giving himself a break" by using a setuid binary. Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research
John R Pierce
2017-Feb-09 21:16 UTC
[CentOS] Serious attack vector on pkcheck ignored by Red Hat
On 2/9/2017 1:03 PM, Leonard den Ottolander wrote:> Not necessarily. Suppose the adversary is aware of a root > exploit/privilege escalation in a random library. Then the heap spraying > allows this attacker to easily trigger this exploit because he is able > to initialize the entire contents of the heap to his liking and thus > call whatever function he likes, including the one that will cause the > root exploit.if the adversary is aware of this exploit and has a login (required to invoke pkexec in the first place), they can simply execute a C program to invoke it, they don't need to mess about with what you're describing. -- john r pierce, recycling bits in santa cruz
Warren Young
2017-Feb-09 21:22 UTC
[CentOS] Serious attack vector on pkcheck ignored by Red Hat
On Feb 9, 2017, at 2:03 PM, Leonard den Ottolander <leonard at den.ottolander.nl> wrote:> > On Thu, 2017-02-02 at 13:40 -0800, Gordon Messmer wrote: >> Escalation *requires* attacking a program in a security context other >> than your own. > > Not necessarily. Suppose the adversary is aware of a root > exploit/privilege escalation in a random library.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. 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. 2. There?s no such thing as SUID libraries. 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. You can point at vulnerable libraries giving data exfiltration and such all day long, but privilege escalation??
Leonard den Ottolander
2017-Feb-09 21:39 UTC
[CentOS] Serious attack vector on pkcheck ignored by Red Hat
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
Gordon Messmer
2017-Feb-09 22:02 UTC
[CentOS] Serious attack vector on pkcheck ignored by Red Hat
On 02/09/2017 01:03 PM, Leonard den Ottolander wrote:> > Not necessarily. Suppose the adversary is aware of a root > exploit/privilege escalation in a random library.There is no such thing as a root exploit in a library. A "root exploit" is one that ends with the attacker executing code as root. That can only be done by attacking an existing process running as root, or by attacking a SUID binary. There are certainly flaws in libraries that lead to code execution, but the exploit will be described in terms of the entire system that enables privilege escalation, which means the attack will be in the context of a daemon, or a SUID binary.> If you read the article carefully the author makes no claims that the > setuid on the binary is a necessity. He clearly states he is "giving > himself a break" by using a setuid binary.No, he doesn't. He gave himself a break by attacking a 32-bit binary instead of the 64 bit one, because causing the heap and the stack to collide in a 64 bit address space is a *lot* more work.> 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.pkcheck doesn't escalate privileges. If they are able to launch a remote exploit which calls pkcheck, they can launch a remote exploit that just calls a shell directly instead. Attacking pkcheck doesn't give them anything extra. Does it not tell you anything that *everyone* is telling you that there is no security exploit in the ability to cause pkcheck to execute code? It's a bug, but it's not a security flaw.
Apparently Analagous Threads
- Serious attack vector on pkcheck ignored by Red Hat
- Serious attack vector on pkcheck ignored by Red Hat
- Serious attack vector on pkcheck ignored by Red Hat
- Serious attack vector on pkcheck ignored by Red Hat
- Serious attack vector on pkcheck ignored by Red Hat