Re: pg_amcheck option to install extension

> On Apr 19, 2021, at 8:06 PM, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Apr 19, 2021 at 07:15:23PM -0700, Mark Dilger wrote:
>> There is another issue to consider.  Installing pg_amcheck in no way
>> opens up an avenue of attack that I can see.  It is just a client
>> application with no special privileges.  But installing amcheck
>> arguably opens a line of attack; not one as significant as
>> installing pageinspect, but of the same sort.  Amcheck allows
>> privileged database users to potentially get information from the
>> tables that would otherwise be invisible even to them according to
>> mvcc rules.  (Is this already the case via some other functionality?
>> Maybe this security problem already exists?)  If the privileged
>> database user has file system access, then this is not at all
>> concerning, since they can already just open the files in a tool of
>> their choice, but I don't see any reason why installations should
>> require that privileged database users also be privileged to access
>> the file system.
>
> By default, any functions deployed with amcheck have their execution
> rights revoked from public, meaning that only a superuser can run them
> with a default installation.  A non-superuser could execute them only
> once GRANT'd access to them.

Correct.  So having amcheck installed on the system provides the database superuser with a privilege escalation attack
vector. I am assuming here the database superuser is not a privileged system user, and can only log in remotely, has no
directaccess to the file system, etc. 

Alice has a database with sensitive data.  She hires Bob to be her new database admin, with superuser privilege, but
doesn'twant Bob to see the sensitive data, so she deletes it first.  The data is dead but still on disk. 

Bob discovers a bug in postgres that will corrupt dead rows that some index is still pointing at.  This attack requires
sufficientprivilege to trigger the bug, but presumably he has that much privilege, because he is a database superuser.
Let'scall this attack C(x) where "C" means the corruption inducing function, and "x" is the indexed key for which dead
rowswill be corrupted. 

Bob runs "CREATE EXTENSION amcheck", and then successively runs C(x) followed by amcheck for each interesting value of
x. Bob learns which of these values were in the system before Alice deleted them. 

This is a classic privilege escalation attack.  Bob has one privilege, and uses it to get another.

Alice might foresee this behavior from Bob and choose not to install contrib/amcheck.  This is paranoid on her part,
butdoes not cross the line into insanity. 

The postgres community has every reason to keep amcheck in contrib so that users such as Alice can make this decision.

No similar argument has been put forward for why pg_amcheck should be kept in contrib.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company