From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Kupershmidt <schmiddy(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Patch to allow users to kill their own queries |
Date: | 2011-12-16 14:38:40 |
Message-ID: | CABUevEzeXK53vtYCvStXEuDGOTLff-88Fz==AvCN1UgWCzn_qw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Friday, December 16, 2011, Greg Smith wrote:
> On 12/16/2011 08:42 AM, Robert Haas wrote:
>
>> the proposed patch would potentially result - in the extremely unlikely
>> event of a
>> super-fast PID wraparound - in someone cancelling a query they
>> otherwise wouldn't have been able to cancel.
>>
>>
>
> So how might this get exploited?
>
> -Attach a debugger and put a breakpoint between the check and the kill
>
Once you've attached a debugger, you've already won. You can inject
arbitrary instructions at this point, no?
> -Fork processes to get close to your target
> -Wait for a process you want to mess with to appear at the PID you're
> waiting for. If you miss it, repeat fork bomb and try again.
> -Resume the debugger to kill the other user's process
>
> If I had enough access to launch this sort of attack, I think I'd find
> mayhem elsewhere more a more profitable effort. Crazy queries, work_mem
> abuse, massive temp file generation, trying to get the OOM killer involved;
> seems like there's bigger holes than this already.
>
"killall -9 postgres" is even easier.
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2011-12-16 14:47:30 | Re: Patch to allow users to kill their own queries |
Previous Message | Magnus Hagander | 2011-12-16 14:37:58 | Re: Patch to allow users to kill their own queries |