3 ms·

ssrf was the entry point, and clickhouse is supposed to be an internal only service, but one could reach it only with that ssrf, so hence less of "scrutiny". Th

by matmuls 10mo ago

ssrf was the entry point, and clickhouse is supposed to be an internal only service, but one could reach it only with that ssrf, so hence less of "scrutiny". The 0day by itself wouldnt be useful, unless an attacker can reach clickhouse, which they usually can't.

thenaturalist 10mo ago
But if they do, prohibiting SQL injection, a critical last mile vulnerability, seems trivial?
- nightpool 10mo ago
  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.
  - wtfse 10mo ago
    That being said, having the ability to send HTTP requests to the internal servers is usually not critical vulnerability. Therefore having Clickhouse low-severity escaping vulnerability actually lead the whole chain to reach code execution. All the other services were requiring me to send special headers, which is not possible most of the SSRF cases :(
    - nightpool 10mo ago
      I see what you're saying, but IMO the actual vulnerability there is that Clickhouse (by default?) was exposed fully unauthenticated and without any header requirement. Allowing completely unauthenticated access to Clickhouse, even read-only, means that they're just asking for issues like this.
- ch2026 10mo ago
  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.
- wtfse 10mo ago
  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/8ae72dcdb45d2ded44845270a980023836005e01 https://github.com/ClickHouse/ClickHouse/pull/74144/commits/...

by matmuls 10mo ago

thenaturalist 10mo ago

But if they do, prohibiting SQL injection, a critical last mile vulnerability, seems trivial?

nightpool 10mo ago
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.
- wtfse 10mo ago
  That being said, having the ability to send HTTP requests to the internal servers is usually not critical vulnerability. Therefore having Clickhouse low-severity escaping vulnerability actually lead the whole chain to reach code execution. All the other services were requiring me to send special headers, which is not possible most of the SSRF cases :(
  - nightpool 10mo ago
    I see what you're saying, but IMO the actual vulnerability there is that Clickhouse (by default?) was exposed fully unauthenticated and without any header requirement. Allowing completely unauthenticated access to Clickhouse, even read-only, means that they're just asking for issues like this.
ch2026 10mo ago
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.
wtfse 10mo ago
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/8ae72dcdb45d2ded44845270a980023836005e01 https://github.com/ClickHouse/ClickHouse/pull/74144/commits/...