> On Apr 19, 2021, at 8:06 PM, Michael Paquier <mich...@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 direct access 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't want 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 sufficient privilege to trigger the
bug, but presumably he has that much privilege, because he is a database
superuser. Let's call this attack C(x) where "C" means the corruption inducing
function, and "x" is the indexed key for which dead rows will 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, but does 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
