Re: FPW compression leaks information

On 04/14/2015 05:42 AM, Robert Haas wrote:
> On Sun, Apr 12, 2015 at 8:38 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)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