Re: leaky views, yet again

(2010/10/06 4:15), Heikki Linnakangas wrote:
> 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.

It contains a custom function with side-effect; such as INSERT the supplied
arguments into private tables.

> 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.
>
I also agree with this attitude.
The case 1 and 2 have differences from others. It allows to expose hidden
values, then people may be able to see these values without any inference.
So, their through-put is relatively faster than others. It means degree of
threat is also higher.

If we try to tacker to the matter 1 and 2, suggestions from Itagaki-san
are still available, because this patch was designed to prevent people
to see hidden data without inferences.

Thanks,
-- 
KaiGai Kohei <kaigai@ak.jp.nec.com>