Re: eval function

On 07/31/2011 09:48 AM, Chris Travers wrote:

> On Sat, Jul 30, 2011 at 9:50 PM, Sim Zacks<sim(at)compulab(dot)co(dot)il> wrote:
>> On one hand the hole can't be plugged because as you mentioned that is the
>> point of the function. On the other hand, if the function is not being run
>> as security definer, the account running it would need to have the rights to
>> do whatever he is injecting. If "1); delete..." would work, then the user
>> could just as easily do Delete... without using the function.
>>
>> The only problem that I see (correct me if I'm wrong) is anonymous injection
>> through a user that has rights that we wouldn't want the actual user to
>> have, which is not recommended in any case.
>>
>>
> You have two issues. One as you mention is privilege escallation.
> The other which you don't is the question of whether you are trying to
> limit your business logic calls to what the sprocs can do. Once you
> add this, that's blown. So the question is whether someone using the
> client to your application server can enter data that gets around the
> limitations of interface and causes other issues. Maybe they can
> overwrite who issued an invoice in order to cover for embezzlement or
> otherwise tamper with the assumptions of default values etc that might
> be in the database..... You never know.
If the user has rights to overwrite the invoice, they can do it
regardless of this function. What you are suggesting is that the user
has rights to overwrite an invoice, but the application layer doesn't
allow them to do it easily. That is also a security risk. You are
talking about web clients, with the connection to the database coming
from the application server. With desktop clients, the database
connection is created on the client, so the pg_hba doesn't know the
difference between login with psql or the application.
This type of issue has to be taken care of with a proper audit trail.

> Now, just because this function is not security definer doesn't mean
> it can't result in privilege escalation. Instead I would suggest
> thinking of this as a "risk" instead of as a "hole."
>
> 1) Do you know everywhere this function is called?
> 2) What if this is ever called by a security definer function?
> 3) If it has an unobtrusive name like eval(), will it be missed on a
> code audit?
Any security definer function should be designed with security in mind.
That is the responsibility of the dba. You can't limit the dba in what
he can do just in case he doesn't know what he is doing. You can
suggest, but if the dba thinks he knows what he is doing, give him all
the tools to do it.
If the function can cause privilege escalation when not in a security
definer function, then I would say there is a serious problem with the
security system of the engine. Can you think of any possibility where a
function would allow privilege escalation when it is not in a security
definer function?

> You are right that by itself this isn't a hole. However it increases
> the risks I think considerably that holes will happen.
>
> Good security IMHO doesn't start with plugging holes. It starts with
> designing so that holes are less likely and less severe. That's why I
> wouldn't. YMMV.
>
> Best Wishes,
> Chris Travers