On Sun, Apr 12, 2015 at 8:38 PM, Heikki Linnakangas <hlinn...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers