`bq_connection` is free-form and copied into BigQuery `connectionId` without policy validation

[rdblue]

This issue was reported to the private Apache Iceberg security mailing list. The submitter is being kept anonymous because the report was sent to a private list. After review, the issue is not considered a serious vulnerability that needs to be kept private, so it is being filed publicly here for tracking and resolution.

Note: this submission was generated by AI. Please review its claims and source references carefully before acting on them.

Summary

Per-table bq_connection is copied directly into BigQuery
connectionId, letting table creators request any delegable
connection resource unless policy is added externally.

In practice that means a caller who is allowed to create tables can
ask Iceberg to attach any BigQuery connection that the catalog's
BigQuery identity is allowed to delegate. If some of those connections
map to stronger service accounts or broader storage access, the caller
can select a more privileged data path than intended.

Affected Maven coordinates

• primary shipped client artifact: org.apache.iceberg:iceberg-bigquery

Attacker prerequisites

• ability to create or update a table with the bq_connection property
• a deployment where the catalog's BigQuery identity is allowed to
  delegate more than one connection resource and does not enforce its
  own allowlist

Impact

• In a shared-catalog deployment, an untrusted table creator can
  request any connection resource that the catalog's BigQuery identity
  is allowed to delegate.
• If some connections map to more privileged service accounts or
  broader storage access, the table creator can bind a table to a
  stronger credential than intended.
• This is a policy-bypass risk, not because the code fabricates
  permissions, but because it does not constrain which already-delegable
  connection can be attached to a table.

Proof status

I reproduced this locally with a targeted reproducer or exploit.
The observed result matches the trigger and impact described above.

Key source references

• org.apache.iceberg.gcp.bigquery.BigQueryTableOperations

[rdblue]

If I understand correctly, an attacker can create a table and specify its connectionId. This is assumed to be a connectionId that the attacker cannot use. There is a second user that has access to use that connectionId. The second user will use the connectionId for the attacker's table. I see two issues with this vector.

First, the attacker isn't getting the user with access to the connectionId to do anything specific, other than use a resource the user has access to. I don't think that it matters that the user may have access to the connectionId for a different purpose. The user has access to it.

Second, it isn't clear how the attacker would be able to successfully create a table with a connectionId that they do not have access to. Wouldn't the table creation fail? Maybe the attacker could create the table with a different one and then update the value to the new connectionId and rely on the initial one begin used for the update?

We could probably check that the connectionId used to create or update the table is the one that is in the update or create request. But nothing stops an attacker from going directly to the API and not using the client. That means this has to be enforced by the catalog service.

I'm going to close this one.