| |||||||||||||
A PostgreSQL flawA PostgreSQL flawPosted Feb 22, 2007 3:29 UTC (Thu) by dw (subscriber, #12017)Parent article: A PostgreSQL flaw
If my memory of PostgreSQL serves me well (come on, it's only been a year!), then then Mallory (the 'untrusted' session) would first need the permission to create new functions before an attack would be successful, no?
(Log in to post comments)
A PostgreSQL flaw Posted Feb 22, 2007 13:46 UTC (Thu) by nix (subscriber, #2304) [Link] Well, you need to have been able to create new functions in some schema (which you can later put in the search path) at some earlier point in time.
That's a rather wide constraint.
(FWIW, Oracle has the equivalent of SECURITY DEFINER be the *default* but avoids this bug by searching the object owner's schema instead for such functions. Perhaps simply prepending the object owner's schema to the search path when within such functions would largely fix the problem...)
A PostgreSQL flaw Posted Feb 23, 2007 23:32 UTC (Fri) by intgr (subscriber, #39733) [Link] No -- Mallory needs access to existing SECURITY DEFINER functions defined by a higher-privilege user. Mallory can only create his own functions, but that way he'll only be able to impersonate himself.
A PostgreSQL flaw Posted Feb 26, 2007 21:15 UTC (Mon) by schabi (subscriber, #14079) [Link] That's not correct. He needs to define his own function or operator that shadows a function or operator used by the privileged function (by having the same name and signature), then arrange the search path so that his function is found first, and then call the privileged function.
In most cases, it even suffices that he creates the function or operator in his own schema, as - by default - that schema precedes the ones that define the built-in operators and functions.
|
|||||||||||||