CoinFabrik/scout-substrate huggingface dataset:
Audit finding: Documentation is incomplete
Project: Acala
Auditor: Trail of Bits
Impact: Low
Likelihood: Difficulty-High
Vulnerability class (audit): Documentation
Vulnerability class (Scout): Code Quality

11. Documentation is incomplete
Severity: Informational
Difficulty: High
Type: Documentation
Finding ID: TOB-ACA-011
Target: documentation

Description:
Several areas of the Acala system would benefit from more thorough documentation. Comprehensive documentation of the system's behaviour is important for informing users of how the system operates, onboarding new employees, as well as verifying correctness of functionality.

The following areas were identified that would benefit from improved documentation:
- Governance processes, which are described both in the wiki and in a hackmd note but neither is comprehensive and there are some points of conflict.
- The various network incentives managed by the incentives module.
- Gas fees.

Exploit Scenario:
Bob joins Acala as a new developer. Unaware of the expected behavior of a particular module, he modifies system parameters as part of a pull request and introduces unexpected behavior into the system.

Recommendation:
Short term, expand and unify the documentation to better cover governance, incentives, and gas fees.
Long term, regularly review public documentation to ensure it is kept up to date with the current system.

Summary: The system's documentation is incomplete, missing details on governance, incentives, and gas fees, which could lead to unexpected behavior.
Audit finding: Overflow on The Libsecp256k1
Project: Astar
Auditor: Quantstamp
Location: frame/custom-signatures/Cargo.toml:23
Impact: High
Vulnerability class (Scout): Dependency
Status: Fixed

QSP-1 Overflow on The Libsecp256k1
Severity: High Risk
Status: Fixed
File(s) affected: frame/custom-signatures/Cargo.toml
Description: In frame/custom-signatures/Cargo.toml (L23): Libsecp256k1 accepts signatures whose R or S parameter is larger than the secp256k1 curve order, which differs from other implementations. This could lead to invalid signatures being verified. This error is resolved in 0.5.0 by adding a check_overflow flag.
Recommendation: Update the Libsecp Library to the latest version (Greater than 0.5.0).

Summary: Libsecp256k1 allowed invalid signatures due to lack of parameter size checks.
Audit finding: Lack of Validation in the 'what' Parameter
Project: Astar
Auditor: Quantstamp
Location: frame/custom-signatures/src/ethereum.rs:44
Impact: Medium
Vulnerability class (Scout): Error Handling and Validation
Status: Mitigated

QSP-2 Lack of Validation in the what Parameter
Severity: Medium Risk
Status: Mitigated
File(s) affected: frame/custom-signatures/src/ethereum.rs
Description: In frame/custom-signatures/src/ethereum.rs (L44): the signable_message function takes as parameters the variable what and then it executes a loop N times such that N is the length of the variable what. The problem here is that there is no limit on the length of this variable, which can cause a denial of service during the execution of this function call.
Recommendation: Enforce a limitation on the size of the what parameter.
Update: 2021-09-17: The original issue was solved by using a double-hashing approach. However, the admin team should be aware that this approach increases the probability of collision and could thus introduce additional risk to the system.

Summary: Lack of length validation in the 'what' parameter could cause a denial of service.
Audit finding: Cross Chain Replay Attack is Possible
Project: Astar
Auditor: Quantstamp
Location: frame/custom-signatures/src/lib.rs
Impact: Medium
Vulnerability class (Scout): Business Logic
Status: Fixed

QSP-3 Cross Chain Replay Attack is Possible
Severity: Medium Risk
Status: Fixed
File(s) affected: frame/custom-signatures/src/lib.rs
Description: Cross chain replay attack is possible for the current custom signature design because there is no information in the signature which blockchain a signature is intended for.
Recommendation: Include the chainId into the signature to distinguish a signature for a specific blockchain from the other blockchains. Reference: Signing Data with MetaMask.
Update: 2021-09-17: The admin team stated that ChainId will be used to fill in the magic number field.

Summary: Cross chain replay attack possible due to lack of blockchain identification in the signature.
Audit finding: Order Logic In Nonce Increment
Project: Astar
Auditor: Quantstamp
Location: frame/custom-signatures/src/lib.rs:113
Impact: Low
Vulnerability class (Scout): Business Logic
Status: Fixed

QSP-4 Order Logic In Nonce Increment
Severity: Low Risk
Status: Fixed
File(s) affected: frame/custom-signatures/src/lib.rs
Description: In frame/custom-signatures/src/lib.rs (L113): in the call function, the first thing verified is the validity of the transaction with the help of the nonce. Once the verification has been done, this nonce will be incremented, and if the following lines have some problems or errors, the nonce will still be incremented, causing improper execution.

Summary: Improper nonce increment logic could cause incorrect transaction execution.
Audit finding: Potential segfault in localtime_r invocations
Project: Astar
Auditor: Quantstamp
Location: Cargo.lock
Impact: Medium
Vulnerability class (audit): SWC-RUSTSEC-2020-0159
Vulnerability class (Scout): Dependency
Status: Acknowledged

QSP-1 Potential segfault in localtime_r invocations
Severity: Medium Risk
Status: Acknowledged
File(s) affected: Cargo.lock
Related Issue(s): SWC-RUSTSEC-2020-0159
Description: In the Cargo.lock file the package chrono with the version 0.4.19 is used, in fact this version is affected by a data race between localtime_r and setenv. You can refer to more details of the vulnerability in the following link: https://rustsec.org/advisories/RUSTSEC-2020-0159
Recommendation: The team should update the chrono version to the latest version.

Summary: Potential segfault in localtime_r invocations due to a data race in chrono 0.4.19.
Audit finding: Mathematical Operations That Lead To Overflow
Project: Astar
Auditor: Quantstamp
Location: /frame/dapps-staking/src/pallet/mod.rs:244,393,408,413,549,552,593,683
Impact: Medium
Vulnerability class (Scout): Arithmetic
Status: Fixed

QSP-2 Mathematical Operations That Lead To Overflow
Severity: Medium Risk
Status: Fixed
File(s) affected: /dapps-staking/src/pallet/mod.rs
Description: In the on_initialize function (file /dapps-staking/src/pallet/mod.rs, L244), the next_era variable is incremented using the + operator, which can cause an overflow. If one uses the debug build, it can cause a panic; however, in release build it will overflow silently. Same issue in lines 393, 408, 413, 549, 552, 593, 683
Recommendation:
• Instead of using the + operator, we recommend using the checked_add function to prevent an overflow.
• Instead of using the x operator, we recommend using the checked_mul function to prevent an overflow.
Update: The team has fixed all the issues except for the era index overflow and number of stakers overflow since these scenarios aren't feasible.

Summary: Overflow risk in mathematical operations using the + operator in on_initialize function.
Audit finding: Missing Validation In Some Variables
Project: Astar
Auditor: Quantstamp
Location: /frame/dapps-staking/src/pallet/mod.rs:327,390,578
Impact: Low
Vulnerability class (Scout): Error Handling and Validation
Status: Fixed

QSP-3 Missing Validation In Some Variables
Severity: Low Risk
Status: Fixed
File(s) affected: dapps/src/pallet/mod.rs
Description:
• In dapps/src/pallet/mod.rs (L327): the unregister function executes a loop N times such that N is the length of the stakers. The problem here is that there is no limit on the length of this variable, which can cause a denial of service during the execution of this function call. Same issue in line 578
• In dapps/src/pallet/mod.rs (L390): the bond_and_stake function verifies if the value value_to_stake is equal to Zero value; if it's the case, the transaction reverts. This verification is not sufficient; we should enforce it by verifying if the value_to_stake is greater than 0.
Recommendation:
* Enforce a limitation on the number of the stakers.
• Verify if value_to_stake is greater than the zero value.
Update:
* The number of stakers is limited by a configurable constant.
• The team did the verification using value_to_stake > Zero::zero()

Summary: Missing validation for stakers length and value_to_stake, leading to potential denial of service.
Audit finding: Order of Validation in Maximum Number of Stakers
Project: Astar
Auditor: Quantstamp
Location: /frame/dapps-staking/src/pallet/mod.rs:400
Impact: Informational
Vulnerability class (Scout): Error Handling and Validation
Status: Fixed

QSP-4 Order of Validation in Maximum Number of Stakers
Severity: Informational
Status: Fixed
Description: In the bond_and_stake function (L400), after updating the ledger value and getting the latest era staking point the number of stakers is verified if it is less than the maximum number of stakers. If it's not the case, the transaction will revert. This verification should be done before updating the ledger value.
Recommendation: The team should verify if we exceed the MaxNumberOfStakersPerContract before setting any variables or doing calculations.

Summary: Validation of maximum number of stakers occurs after updating ledger values, risking improper transactions.
Audit finding: Runtime template waives XCM message delivery fees
Project: PolkadotRunetimeTemplates
Auditor: Security Research Labs
Location: runtime/src/xcm_configs.rs
Impact: Critical
Vulnerability class (Scout): Denial of Service (DoS) and Spamming
Status: Closed [3] [Online]. Available: https://github.com/OpenZeppelin/polkadot-generic-runtime-template/pull/159.

3.2.1 Runtime template waives XCM message delivery fees
An attacker can cause network congestion causing delay in message deliveries or discards and storage exhaustions.

To avoid congestion and spamming of messages in the network via XCM, a fee is charged for message delivery to ensure fairness and optimal message delivery time amongst all the participants. This fee is configured in the runtime construct through use of FeeManager type.

In the template for XCM runtime configuration for OpenZeppelin, the FeeManager was set to the Rust unit type "()". In the Polkadot-SDK, this implementation effectively waives the delivery fees.

Thereby all fee-based congestion control mechanisms become ineffective since the fees are not actually charged. An attacker can cause congestion, possibly leading to long delays in message delivery, storage exhaustion and/or dropping of messages.

Recommendation: Implement a fee for XCM message delivery and follow the fix implemented in the runtime update v1.3.

Summary: The runtime waives XCM message delivery fees, enabling attackers to cause network congestion and storage exhaustion.
Audit finding: No XCM delivery fees configured for sibling parachain messages
Project: PolkadotRunetimeTemplates
Auditor: Security Research Labs
Location: runtime/src/lib.rs
Impact: High
Vulnerability class (Scout): Denial of Service (DoS) and Spamming
Status: Closed [7] [Online]. Available: https://github.com/OpenZeppelin/polkadot-generic-runtime-template/pull/156/files.

3.2.2 No XCM delivery fees configured for sibling parachain messages
Attackers may send spam messages across chains without paying a fee.

To ensure fairness among users and prevent spamming of messages across chains, an adequate fee mechanism must be implemented for sending the XCM message.

Currently, there are no fees charged for delivering XCM messages across parachains. In the template runtime configuration, this is configured through PriceForSiblingDelivery by NoPriceForMessageDelivery.

Attackers may send spam messages across chains without paying a fee. Excessive messages could lead to XCM queue size exhaustion by excessive storage usage until messages are delivered. This could also lead to delays in message delivery for other users.

Recommendation: Charge adequate message delivery fees in the runtime configuration template. To prevent excessive delivery times and storage exhaustion, an exponential fee mechanism should be used as configured in Kusama.

Summary: No XCM delivery fees allow attackers to spam sibling parachains, causing queue exhaustion and delays.
Audit finding: Incorrect runtime weights for XCM and the Message Queue pallet
Project: PolkadotRunetimeTemplates
Auditor: Security Research Labs
Location: runtime/src/xcm_configs.rs
Impact: High
Vulnerability class (Scout): Weight Management
Status: Closed [9] [Online]. Available: https://github.com/OpenZeppelin/polkadot-generic-runtime-template/pull/153.

3.2.3 Incorrect runtime weights for XCM and the Message Queue pallet
As these pallet extrinsic weights are not dependent on the actual runtime configuration, this could lead to underweight extrinsics.

OpenZeppelin’s runtime template constructs runtime logics with FRAME pallets in its configuration. Appropriate benchmarking is required for these pallets to ensure its actual runtime performance. This will effectively transform into charging adequate fees for extrinsics execution.

For example, the runtime weights for pallet XCM are configured using TestWeightInfo. Similarly, for Generalized Message Queue, runtime weights are configured to be Zero as type WeightInfo = ().

As these pallet extrinsic weights are not dependent on the actual runtime configuration, this could lead to underweighted extrinsics. Setting the weights to () effectively makes it a zero-cost execution for extrinsics. Both scenarios lead to attackers spamming and bloating the network storage for free.

Recommendation: All pallet extrinsics, even the Substrate ones, should be benchmarked with the actual runtime configuration by including them in the define_benchmarks! block. A best practice example can be found in the Kusama runtime implementation.

Summary: Incorrect runtime weights allow zero-cost extrinsics, enabling spamming and network storage bloat.
Audit finding: Insufficient benchmarking for runtime pallets
Project: PolkadotRunetimeTemplates
Auditor: Security Research Labs
Location: runtime/src.rs
Impact: High
Vulnerability class (Scout): Weight Management
Status: Closed [13] [Online]. Available: https://github.com/OpenZeppelin/polkadot-generic-runtime-template/pull/149/files#diff-0ec06ea58bd455f09ce6b3bb4c2c1c0d37bda51c1e1be2151c560c9c973959ec.

3.2.4 Insufficient benchmarking for runtime pallets
Missing or incorrect runtime benchmarks result in overweight or underweight extrinsics. This can lead to low-effort attacks such as spamming, storage bloating, and block stalling.

Pallets with extrinsics must have an accurate weight function which factors in storage, database access, and computation. The reuse of the substrate template and failing to benchmark weights may result in a mismatch of computational requirements and the cost of execution.

Some pallets use pre-defined weights in the runtime configuration but are not included in the runtime benchmarks. The pallets affected are:
- cumulus_pallet_parachain_system
- parachain_info
- pallet_proxy
- pallet_utility
- pallet_multisig
- pallet_transaction_payment
- pallet_xcm

Additionally, the benchmarks for all the pallets are using SubstrateWeights, which were benchmarked according to the substrate-node template, instead of the actual template runtime.

Excluding pallets with configured weights from benchmarking and using the substrate-node template runtime weights may result in overweight or underweight extrinsics in the runtime environment. This potentially leads to low-effort attacks such as spamming, storage bloating, and block stalling when invoking extrinsics.

Recommendation: Include the above-mentioned pallets in the try_benchmarks! macro for appropriate runtime benchmarks. Fix all the default benchmarking with actual runtime; please refer to the Glutton-Kusama parachain as a best practice example.

Summary: Insufficient benchmarking results in overweight or underweight extrinsics, enabling spamming and block stalling.