You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Attackers can get information about the base node via gRPC errors, even when the
user has set the configuration to obscure the errors.
The particular method that fails to obscure the errors is get_new_block_blob,
where the obscure_error_if_true call is missing:
let new_block = match
handler.get_new_block(block_template).await{Ok(b) => b,Err(CommsInterfaceError::ChainStorageError(ChainStorageError::InvalidAr
guments { message, .. })) => {returnErr(Status::invalid_argument(message));},Err(CommsInterfaceError::ChainStorageError(ChainStorageError::CannotCal
culateNonTipMmr(msg))) => {let status = Status::with_details(
tonic::Code::FailedPrecondition,
msg,Bytes::from_static(b"CannotCalculateNonTipMmr"),);returnErr(status);},Err(e) => returnErr(Status::internal(e.to_string())),};
Errors related to the serialization of the blob also will not be obscured:
There are also other inconsistencies in the usage of the obscure_error_if_true
method. For example, the majority of invalid arguments are not obscured, possible
to let the requester know what they must correct for their request to succeed. But
some, like errors related to the public key serialization in get_shard_key, are
obscured:
let public_key = PublicKey::from_bytes(&request.public_key).map_err(|e| obscure_error_if_true(report_error_flag,Status::invalid_argument(e.to_string())))?;
The text was updated successfully, but these errors were encountered:
Description
---
Consistently applied `obscure_error_if_true` within
`base_node_grpc_server.rs`
Closes#5857
Motivation and Context
---
See #5857
How Has This Been Tested?
---
Pass existing tests
What process can a PR reviewer use to test or verify this change?
---
Code walk-through
<!-- Checklist -->
<!-- 1. Is the title of your PR in the form that would make nice release
notes? The title, excluding the conventional commit
tag, will be included exactly as is in the CHANGELOG, so please think
about it carefully. -->
Breaking Changes
---
- [x] None
- [ ] Requires data directory on base node to be deleted
- [ ] Requires hard fork
- [ ] Other - Please specify
<!-- Does this include a breaking change? If so, include this line as a
footer -->
<!-- BREAKING CHANGE: Description what the user should do, e.g. delete a
database, resync the chain -->
Attackers can get information about the base node via gRPC errors, even when the
user has set the configuration to obscure the errors.
The particular method that fails to obscure the errors is get_new_block_blob,
where the obscure_error_if_true call is missing:
Errors related to the serialization of the blob also will not be obscured:
There are also other inconsistencies in the usage of the obscure_error_if_true
method. For example, the majority of invalid arguments are not obscured, possible
to let the requester know what they must correct for their request to succeed. But
some, like errors related to the public key serialization in get_shard_key, are
obscured:
The text was updated successfully, but these errors were encountered: