Re: Why does creating logical replication subscriptions require superuser?

Hi!

> 21 янв. 2021 г., в 21:20, Paul Martinez <paulmtz(at)google(dot)com> написал(а):
>
> Hey, all,
>
> I'm working with native logical replication, and I don't fully understand
> why logical replication subscribers need to be superusers, nor do I fully
> understand the implication of some of the comments made on this page:
>
> https://www.postgresql.org/docs/current/logical-replication-security.html
>
>> A user able to modify the schema of subscriber-side tables can execute
>> arbitrary code as a superuser.
>
> Does "execute arbitrary code" here really mean executing arbitrary code on the
> machine that is running Postgres, or simply running arbitrary SQL in the
> replicating database? Would it only be able to modify data in the database
> containing the subscription, or could it modify other databases in the same
> cluster? Is there any "blast-radius" to the capabilities gained by such a user?
I suspect it means what it states. Replication is running under superuser and e.g. one can add system catalog to subscription.
Or exploit this fact other way. Having superuser you can just COPY FROM PROGRAM anything.

> According to the commit message that added this text, the callout of this
> point was added as result of CVE-2020-14349, but the details there don't
> really help me understand what the concern is here, nor do I have a deep
> understanding of various features that might combine to create a vulnerability.
>
> I'm not sure what arbitrary code could be executed, but my rough guess, based
> on some of the other text on that page, is that custom triggers, written in
> an arbitrary language (e.g., Python), would run arbitrary code and that is
> the concern. Is that correct? And, if so, assuming that Python triggers were
> the only way to execute arbitrary code, then simply building Postgres without
> Python support would prevent users that can modify the schema from executing
> code as superuser. What is the full set of features that could lead to running
> arbitrary code in this scenario? Is it just all the different languages that
> can be used to write triggers?
We cannot build PostgreSQL without SQL.

> Essentially, I'm wondering what a loose proof-of-concept privilege escalation
> vulnerability would look like if a non-superuser can modify the schema of
> subscriber-side tables.

> On a related note, what happens if a superuser creates a subscription, and then
> is demoted to a regular user? My understanding is that the worker that applies
> the logical changes to the database connects as the user that created the
> subscription, so would that prevent potential vulnerabilities in any way?

Subscription operations must run with privileges of user that created it. All other ways are error prone and leave subscriptions only in superuser's arsenal.

Thanks!

Best regards, Andrey Borodin.