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
thereare plenty of built-in fúnctions that can regurgitate the argument verbatim in an error message. Using that, you
canbuild 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
aWHERE 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
emitsthe argument in an ERROR> falls into this category. You can access any value in the table, but only> one at a time
becauseERROR 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
togetherto 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
themcompletely. And for many> applications, probing attacks are a non-issue. For example, imagine table> of usernames
andpasswords, with a view that lets you see your own password.> Probing for other people's passwords would be useless,
youmight 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
losemy 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>