On 05.10.2010 21:48, Tom Lane wrote:
Heikki Linnakangas<heikki.linnakan...@enterprisedb.com> writes:
On 05.10.2010 21:08, Greg Stark wrote:
If the users that have select access on the view don't have DDL access
doesn't that make them leak-proof for those users?
No. You can use built-in functions for leaking data as well.
There's a difference between "can be used to extract data wholesale"
and "can be used to probe for the existence of a specific value".
Define wholesale. I'm also not too worried about probing attacks, where
you can ask "does this value exist?", but there are plenty of built-in
fúnctions that can regurgitate the argument verbatim in an error
message. Using that, you can build a script to fetch the value for every
row in the table, one row at a time. It's orders of magnitude slower
than "SELECT * FROM table", but orders of magnitude faster than probing
for every possible value for every row.
> We might need to start using more specific terminology than "leak".
Yeah. There are many different categories of leakage:
1. Wholesale retrieval of all rows. For example, a custom function that
emits the argument with a NOTICE, used in a WHERE clause.
2. Retrieval of a given value in an arbitrary attacker-chosen row. Using
a function like text to integer cast that emits the argument in an ERROR
falls into this category. You can access any value in the table, but
only one at a time because ERROR causes a rollback.
3. Retrieval of some values, not attacker-chosen. For example,
statistics might leak the top 100 values.
4. Probing attacks. Let's you check if a row with given value exists.
5. Leakage of statistical information. Lets you know roughly how many
rows there are in a table, for example.
There's some fuzziness in those too, you might be able to probe for
values in an indexed column but not others, for example. Or you might be
able to retrieve all values in one column, or all values in another
column, but not put them together to form the original rows in the table.
IMHO we don't need to protect against 5. Probing attacks can be nasty,
but it's next to impossible to protect from them completely. And for
many applications, probing attacks are a non-issue. For example, imagine
table of usernames and passwords, with a view that lets you see your own
password. Probing for other people's passwords would be useless, you
might as well try to log in with the guessed password directly.
Retrieval of some non-attacker chosen rows, like from statistics, would
be nice to avoid where feasible, but I won't lose my sleep over it. I do
think we need to protect against 1 and 2.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
