On Thu, Oct 7, 2010 at 9:10 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Robert Haas (robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
