(2010/10/06 4:15), Heikki Linnakangas wrote:
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.
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 <kai...@ak.jp.nec.com>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
