On Sun, Apr 12, 2015 at 8:38 PM, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> Care to name some? This is certainly quite cumbersome to exploit, but it's
> doable.
>
> We've talked a lot about covert channels and timing attacks on RLS, but this
> makes me more worried because you can attack passwords stored in pg_authid.
Well, one thing to think about is that, if we're going to take this
kind of attack seriously, it could be used on user data, too. I mean,
you've just got to be able to get a row into the same block as the row
you want to find out something about, and there's no reason that need
be true only for pg_authid. And, even if you ban access to
information on the pg_xlog insert location, what's to prevent someone
from gleaning similar information via a timing attack on the
compression itself? You can even get some information from figuring
out, by trial and error, how much you need to expand a row to get it
to spill over into another block. If there happens to be enough
free-space on the page where the row is located to allow a HOT update,
you can repeatedly update it until it gets moved to some unrelated
page. Granted, knowing the length of an unseen row isn't as good as
knowing the contents, but it's still potentially useful information.
As to RLS - yeah, that's where I think a lot of the possible covert
channel attacks are. But it doesn't have to be RLS per se. It can
be, for example, a table some of whose contents you expose via a
security barrier view. It can be a security-definer function that you
call and it returns some data that you don't have rights to view
directly. Basically, it can be any table to which you have some
access, but not complete access. Then you can use timing attacks,
scrutinize EXPLAIN plans for clues, look at CTIDs, and so on.
Basically, I'm worried that it's going to be completely impractical to
prevent a certain amount of information leakage when you have partial
access to a table, and that in a largely-futile effort to try to
prevent it, we'll end up making a whole bunch of things (like the WAL
insert position) super-user only, and that this will in fact be a net
reduction in security because it'll encourage people to use the
superuser account more.
Perhaps that concern is ill-founded, but that's what I'm worried about.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company