On 02/15/2017 09:37 AM, Leonard den Ottolander wrote: > Hello Warren, > > On Thu, 2017-02-09 at 15:27 -0700, Warren Young wrote: >> 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? > > So the heap is set with data provided by the (local) attacker who could > initialize it to his liking using either of the two memory leaks in the > options parsing. > > The heap, that is entirely under the control of the attacker, now > contains a call to a library with parameters such that it invokes a zero > day kernel escalation privilege exploit. And now the exploit will run > because pkcheck allowed the attacker to initialize its entire heap via > the command line. > > Had the two memory leaks in the pkcheck options parsing been fixed the > attacker should have looked for another path to leverage his zero day. > > So the mere fact that an untrusted user is able to massage the heap of a > binary (pkcheck in this case) to run whatever code he wants is a serious > attack vector and thus those two memory leaks should be fixed. Because > they allow bad people to leverage attacks with much more ease. > What people are trying to point out to you is: 1. The 'user' that the 'atacker' can run things as is themselves .. AND 2. They already have shell access on the machine in question and they can already run anything in that shell that they can run via what you are pointing out. 3. If they have access to a zeroday issue that give them root .. they can just use that via their shell that they already have (that you gave them, which they are using) to get root .. they therefore don't need to use this issue at all. ==== All of that said, all memory leaks (and any other bugs) should be fixed. It is just NOT a major security issue.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx https://lists.centos.org/mailman/listinfo/centos
