The security team received a report that pg_recvlogical was
careless about quoting --option arguments that are passed
into the START_REPLICATION command given to the server. In
principle this'd allow an attacker to inject unwanted stuff
into START_REPLICATION's options. However, we found it really
hard to envision a situation where somebody would be passing
strings obtained from untrustworthy sources to pg_recvlogical,
especially given that anything to do with replication already
requires pretty high privilege. So we're electing to treat this
as a garden-variety bug rather than one requiring the CVE process.
Looking around revealed other places also being sloppy about
quoting strings inserted into replication commands, but the same
who-would-do-that argument applies to them too. So here is a
patch that tries to clean all that up.
(I envision back-patching this all the way, but have not yet
looked at whether the back branches will require adjustments.)
Thanks for the patch!
I looked at the patch and big +1 on handling quoting wherever
feasible rather than depending on some parent or child function to do that.
Not only does the patch fix quoting, it also fixes some
workflows (it is on the right side, so I think adding a test
is optional though some ERROR / behaviour would change,
for example some earlier "Syntax error" would fall through
the whole function).
$ pg_receivewal -D wal --slot=999 --no-sync
pg_receivewal: error: could not send replication command "READ_REPLICATION_SLOT": ERROR: syntax error
pg_receivewal: disconnected; waiting 5 seconds to try again
pg_receivewal: error: could not send replication command "READ_REPLICATION_SLOT": ERROR: syntax error
[loops]
The above works fine post the patch. Even for libpqwalreceiver
issue when publication_names containing a backslash, as mentioned
in your patch commit, earlier subscription used to be permanently stuck due
to that addition of E.
All in all, I did not find any issues with the patch, lgtm.
Regards,
Ayush
