Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

🛡️ Not All Storage Elements Are Exposed Through Queries #555

Closed
ccamel opened this issue May 23, 2024 · 1 comment · Fixed by #576
Closed

🛡️ Not All Storage Elements Are Exposed Through Queries #555

ccamel opened this issue May 23, 2024 · 1 comment · Fixed by #576
Assignees
Labels
security audit Categorizes an issue or PR as relevant to Security Audit

Comments

@ccamel
Copy link
Member

ccamel commented May 23, 2024

Note

Severity: Low
target: v5.0.0 - Commit: cde785fbd2dad71608d53f8524e0ef8c8f8178af
Ref: OKP4 CosmWasm Audit Report v1.0 - 02-05-2024 - BlockApex

Description

The Cognitarium and Objectarium contracts exhibit limitations in their query functionalities. This forces users and other contracts to perform a raw query to read the stored value, tying their code to the current implementation of the cognitarium contract, which is error-prone.

  • Cognitarium Contract Limitations: This contract lacks query functions for critical state variables such as NAMESPACE_KEY_INCREMENT and BLANK_NODE_IDENTIFIER_COUNTER. These variables are fundamental for tracking the increments of namespace keys and the identifiers for blank nodes, pivotal for organizing and retrieving semantic data. The absence of query functions for these variables restricts the ability to monitor and manage internal state changes effectively.
  • Objectarium Contract Limitations: Similarly, the Objectarium contract does not provide adequate query functions for accessing important metadata about buckets, such as the owner details, statistics (size, compressed_size, object_count), and other configuration parameters. This limitation hinders users or applications from retrieving essential information that could assist in assessing the usage, management, and ownership of buckets.

Recommendation

We recommend exposing a smart query that returns the above-mentioned elements.

@ccamel ccamel added the security audit Categorizes an issue or PR as relevant to Security Audit label May 23, 2024
@ccamel
Copy link
Member Author

ccamel commented Jun 10, 2024

  1. Cognitarium

As far as the Cognitarium contract is concerned, the limitations on the state variables mentioned (NAMESPACE_KEY_INCREMENT and BLANK_NODE_IDENTIFIER_COUNTER) are, in my view, implementation details, and as such should not be exposed, and moreover may change in the future. Additionally, as mentioned in the audit report, it is still possible to make targeted raw queries.

For instance, the NAMESPACE_KEY_INCREMENT can be retrieved as follows:

➜ okp4d query wasm contract-state raw okp41cd4zj2hw48mwyc4h2knlk863q7sg534j8z4lfpphulaxvsmv3jhsphstwf $(echo -n "namespace_key" | xxd -p) --node https://api.drunemeton.okp4.network:443/rpc --output json | jq -r ".data | @base64d"
"19"

However, this approach is suitable for diagnostic or specific analysis purposes, which require a good understanding of the implementation of the smart contract.

  1. Objectarium

Regarding the Objectarium contract, it is true that statistics should be returned with the information about the bucket. This would allow users or applications to retrieve essential information necessary for assessing usage, management, and ownership of the buckets.

@ccamel ccamel self-assigned this Jun 10, 2024
@ccamel ccamel linked a pull request Jun 11, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security audit Categorizes an issue or PR as relevant to Security Audit
Projects
Status: ✅ Done
Development

Successfully merging a pull request may close this issue.

1 participant