CVE-2018-25098: Operation on a Resource after Expiration or Release (CWE-672)
value: ** UNSUPPORTED WHEN ASSIGNED ** A vulnerability was found in blockmason credit-protocol. It has been declared as problematic. Affected by this vulnerability is the function executeUcacTx of the file contracts/CreditProtocol.sol of the component UCAC Handler. The manipulation leads to denial of service. This product does not use versioning. This is why information about affected and unaffected releases are unavailable. The patch is named 082e01f18707ef995e80ebe97fcedb229a55efc5. It is recommended to apply a patch to fix this issue. The associated identifier of this vulnerability is VDB-252799. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.
CWE description: The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
CVSS v3 base score: 7.5
Published: 2024-02-04T17:15Z
Repository: https://github.com/blockmason/credit-protocol
Language: Other
Files changed: contracts/CreditProtocol.sol
Commit date: 2018-04-11 09:28:33 -0700
Commit message: 🔒 Fix DoS vulnerability in Credit Protocol contract

`#executeUcacTx` is an inexpensive and unauthenticated function that
increases the transaction counter for a UCAC without actually
performing a transaction, up to that UCAC's transaction limit.

A motivated attacker can call this function continuously to perform
a denial-of-service (DoS) attack on a UCAC, preventing legitimate
transactions using that UCAC from being processed.

Once started, this attack can be maintained indefinitely.

Potential mitigations/effects on a live contract include:

 * An attack on a UCAC may incentivize its stakeholders to unstake
   their tokens.

 * The fewer tokens staked in a UCAC, the less expensive the attack
   becomes to perform and maintain.

 * Staking more tokens in the UCAC will increase the transaction limit,
   thus increasing the cost to perform and maintain the attack.

The best mitigation for this attack, then, for a live contract, would
be for token holders to stake enough tokens in the affected UCAC to
make the attack too expensive for the attacker to maintain.

Diff: diff --git a/contracts/CreditProtocol.sol b/contracts/CreditProtocol.sol
index ddf6d27..5488c7c 100644
--- a/contracts/CreditProtocol.sol
+++ b/contracts/CreditProtocol.sol
@@ -103,11 +103,11 @@ contract CreditProtocol is Ownable {
         uint256 currentDecay = totalStaked / 3600 * (now - ucacs[_ucacContractAddr].lastTxTimestamp);
         uint256 adjustedTxLevel = ucacs[_ucacContractAddr].txLevel < currentDecay ? 0 : ucacs[_ucacContractAddr].txLevel - currentDecay;
         return adjustedTxLevel;
     }
 
-    function executeUcacTx(address _ucacContractAddr) public {
+    function executeUcacTx(address _ucacContractAddr) private {
         uint256 txLevelBeforeCurrentTx = currentTxLevel(_ucacContractAddr);
         uint256 txLevelAfterCurrentTx = txLevelBeforeCurrentTx + 10 ** 27 / txPerGigaTokenPerHour;
         require(ucacs[_ucacContractAddr].totalStakedTokens >= txLevelAfterCurrentTx);
         require(ucacs[_ucacContractAddr].totalStakedTokens >= tokensToOwnUcac);
         ucacs[_ucacContractAddr].lastTxTimestamp = now;

Vulnerable code:     function executeUcacTx(address _ucacContractAddr) public {
Fixed code:     function executeUcacTx(address _ucacContractAddr) private {