Re: leaky views, yet again

On Thu, Oct 7, 2010 at 9:10 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Thu, Oct 7, 2010 at 2:02 AM, Heikki Linnakangas
>> > Looks good. It gives the impression that you need to be able to a create
>> > custom function to exploit, though. It would be good to mention that
>> > internal functions can be used too, revoking access to CREATE FUNCTION does
>> > not make you safe.
>>
>> OK, second try attached.
>
> This might be overly pedantic, but I don't think 'tampering' gives the
> right impression.

I'm open to suggestions.

> Also, there's a marked difference between viewing
> data by using built-ins such as casting (since you'll only get to see
> the first value in a column that fails the cast) and being able to write
> a function that pulls out every row of the table and dumps it into
> another table.

Well, that's why I give the more serious example first. Even with
casting failures, there's a good chance you can probe a bunch of
different rows by throwing random filter conditions into the clause.

(function_that_returns_false() OR (name = 'some_constant' AND number::box)

> I think it'd have a much bigger impression if you went
> ahead and changed the 'raise notice' to an 'insert into table x;'.

Possibly, but it makes the example slightly longer, and I think it's
clear enough as-is.

> Also, even if you can't create functions (due to lack of create
> privileges on any schema), you could use DO clauses now.  Revoking
> usage rights on all languages should prevent both though.

I don't see how to make it work with a DO clause.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company