rdblue opened a new issue, #16469:
URL: https://github.com/apache/iceberg/issues/16469
> 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
Remote config and table metadata can pick client-side class names that
are instantiated before subtype checks, giving malicious catalogs a
client-side constructor execution primitive.
The crucial detail is that class lookup initializes the selected class
before Iceberg verifies that it implements the expected interface. By
the time the bad type is rejected, static initializers and constructor
side effects from the attacker-chosen class have already run.
# Affected Maven coordinates
* primary shipped client artifact: `org.apache.iceberg:iceberg-core`
# Attacker prerequisites
* control over a catalog or table property that selects an
implementation class, such as `file-io-impl`, `metrics-reporter-impl`,
`rest.client.tls.configurer-impl`, or `write.location-provider.impl`
* a target Iceberg process whose classpath already contains a gadget
class with dangerous static-initializer or constructor side effects
# Impact
* A malicious or compromised REST catalog can drive client-side
constructor execution by returning class names such as `file-io-impl`,
`metrics-reporter-impl`, or `rest.client.tls.configurer-impl`.
* A malicious table owner can do the same for writers via
`write.location-provider.impl`.
* Because the chosen class is initialized during lookup and the
constructor runs before the cast check, this is stronger than a normal
“bad class name” failure.
Static initializer side effects and constructor side effects from
attacker-selected classes already present on the client classpath can
run first.
* In practical terms, this is a client-side code-execution primitive
against the Iceberg process when a suitable gadget class is present on
the classpath.
It does not load new bytecode from the network, but it can remotely
trigger execution of existing code in the target process.
# 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.common.DynConstructors
* org.apache.iceberg.CatalogUtil
* org.apache.iceberg.rest.HTTPClient
* org.apache.iceberg.LocationProviders
* org.apache.iceberg.rest.responses.ConfigResponse
* org.apache.iceberg.rest.RESTSessionCatalog
* org.apache.iceberg.rest.RESTTableOperations
Current severity assessment [2]: Important
[1] https://iceberg.apache.org/security/
[2] https://security.apache.org/blog/severityrating/
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
