Re: leaky views, yet again - Mailing list pgsql-hackers

On 05.10.2010 21:48, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@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