Re: leaky views, yet again
От | KaiGai Kohei |
---|---|
Тема | Re: leaky views, yet again |
Дата | |
Msg-id | 4CABC897.4060207@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: leaky views, yet again (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
(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>
В списке pgsql-hackers по дате отправления: