But if they do, prohibiting SQL injection, a critical last mile vulnerability, seems trivial?
Sure, it’s a bug they can fix. But it’s more the setup itself that’s the issue. For example clickhouse’s HTTP interface would normally require user/pass auth and not have access to all privileges. Clickhouse has a table engine that maps to local processes too (eg select from a python process you pipe stdin into).
No need for postgres if you have a fully authenticated user.
hey this is the author. Thanks for everyones comment here guys.
There as a actually a vulnerability Clickhouse, which helps you to execute any query on the remote postgresl. By default, you can't execute any random query! This bug was seperately reported to the Clickhouse and has been fixed seperately https://github.com/ClickHouse/ClickHouse/pull/74144/commits/...
The author already had basically full Clickhouse querying abilities, and Clickhouse lets you run arbitrary SQL on postgres, the fact that the author used a read-only command to execute it wasn't the author bypassing a security boundary (anyone with access to the Clickhouse DB also had access to the Postgres DB), it was just a gadget that made the SSRF more convenient. They could have escalated it into a different internal HTTP API instead.