On 04/14/2015 05:42 AM, Robert Haas wrote:
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.
Sure.
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?
Yep, that's another vector. Even more fiddly than the record size, but
nevertheless.
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.
True as well. That's not an issue for the MD5 hashes stored in
pg_authid, they all have the same length, but it can be for application
data.
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.
I'm not a big fan of locking down WAL position information either. If we
have to treat the current WAL position is security-sensitive
information, we're doing something wrong.
But I don't want to just give up either. One option is to make this
controllable on a per-table basis, as Amit suggested. Then we could
always disable it for pg_authid, add a suitable warning to the docs, and
let the DBA enable/disable it for other tables. It's a bit of a cop-out,
but would fix the immediate problem.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
