GPT Review not-so-smart-contracts/algorand #278
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
S3v3ru5
reviewed
Apr 14, 2023
| @@ -1,18 +1,17 @@ | |||
| # Access Controls | |||
|
|
|||
| Lack of appropriate checks for application calls of type UpdateApplication and DeleteApplication allows attackers to update application’s code or delete an application entirely. | |||
| Inadequate checks for application calls of type UpdateApplication and DeleteApplication can allow attackers to alter an application's code or delete it entirely. | |||
There was a problem hiding this comment.
We should probably stick with previously used update instead of alter an (?)
There was a problem hiding this comment.
+1 , update is more appropriated here
S3v3ru5
reviewed
Apr 14, 2023
|
|
||
| Note: From Teal v6, Applications can also be rekeyed by executing an inner transaction with "RekeyTo" field set to a non-zero address. Rekeying an application allows to bypass the application logic and directly transfer Algos and assets of the application account. | ||
| Note: Starting from Teal v6, applications can also be rekeyed by executing an inner transaction with the "RekeyTo" field set to a non-zero address. Rekeying an application allows for bypassing the application logic and directly transferring Algos and assets of the application account. |
There was a problem hiding this comment.
We should replace
Starting from Teal v6, applications can also be
with
Starting from Teal v6, application accounts can also be
S3v3ru5
approved these changes
Apr 14, 2023
montyly
reviewed
Apr 17, 2023
| @@ -1,18 +1,17 @@ | |||
| # Access Controls | |||
|
|
|||
| Lack of appropriate checks for application calls of type UpdateApplication and DeleteApplication allows attackers to update application’s code or delete an application entirely. | |||
| Inadequate checks for application calls of type UpdateApplication and DeleteApplication can allow attackers to alter an application's code or delete it entirely. | |||
There was a problem hiding this comment.
+1 , update is more appropriated here
|
|
||
| ## Exploit Scenarios | ||
|
|
||
| A stateful contract serves as a liquidity pool for a pair of tokens. Users can deposit the tokens to get the liquidity tokens and can get back their funds with rewards through a burn operation. The contract does not enforce restrictions for UpdateApplication type application calls. Attacker updates the approval program with a malicious program that transfers all assets in the pool to the attacker's address. | ||
| A stateful contract functions as a liquidity pool for two tokens. Users can deposit these tokens to acquire liquidity tokens and can retrieve their funds along with rewards via a burn operation. The contract, however, does not enforce any restrictions for UpdateApplication type application calls. An attacker can update the approval program with a malicious program that transfers all the assets in the pool to their address. |
There was a problem hiding this comment.
a stateful contract functions should be change, as function as a specific meaning.
|
|
||
| ## Recommendations | ||
|
|
||
| - Set proper access controls and apply various checks before approving applications calls of type UpdateApplication and DeleteApplication. | ||
| - Implement appropriate access controls and conduct various checks before approving application calls of type UpdateApplication and DeleteApplication. |
There was a problem hiding this comment.
conduct should be reverted I think
|
|
||
| - Use [Tealer](https://github.com/crytic/tealer) to detect this issue. | ||
| - Utilize [Tealer](https://github.com/crytic/tealer) to identify this issue. |
There was a problem hiding this comment.
This line should be reverted I think
|
|
||
| Lack of verification of asset id in the contract allows attackers to transfer a different asset in place of the expected asset and mislead the application. | ||
| Failing to verify the asset ID in a contract can allow attackers to transfer a different asset instead of the expected one, potentially misleading the application. |
There was a problem hiding this comment.
Lack of verification was better I think.
|
|
||
| ## Description | ||
|
|
||
| Contracts accepting and doing operations based on the assets transferred to the contract must verify that the transferred asset is the expected asset by checking the asset Id. Absence of check for expected asset Id could allow attackers to manipulate contract’s logic by transferring a fake, less or more valuable asset instead of the correct asset. | ||
| Contracts that accept and perform operations based on assets transferred to them must verify that the transferred asset is indeed the expected asset by checking the asset ID. Neglecting to check the expected asset ID could enable attackers to manipulate the contract's logic by transferring a fake, less valuable, or more valuable asset instead of the correct one. |
| @@ -1,18 +1,18 @@ | |||
| # Denial of Service | |||
|
|
|||
| When a contract does not verify whether an account has opted in to an asset and attempts to transfer that asset, an attacker can DoS other users if the contract's operation is to transfer asset to multiple accounts. | |||
| A denial of service (DoS) attack can occur when a contract does not verify whether an account has opted into an asset and then attempts to transfer that asset. If the contract's operation involves transferring an asset to multiple accounts, an attacker can use this weakness to launch a DoS attack against other users. | |||
There was a problem hiding this comment.
Note to myself: continue the review from here
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.