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

Protocol is not ERC-1155 compliant #299

Open
c4-bot-10 opened this issue Dec 8, 2023 · 9 comments
Open

Protocol is not ERC-1155 compliant #299

c4-bot-10 opened this issue Dec 8, 2023 · 9 comments
Labels
bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue grade-a insufficient quality report This report is not of sufficient quality primary issue Highest quality submission among a set of duplicates QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax

Comments

@c4-bot-10
Copy link
Contributor

Lines of code

https://github.com/code-423n4/2023-11-shellprotocol/blob/main/src/ocean/Ocean.sol#L317-L366

Vulnerability details

Impact

The Ocean contract is not fully compliant with the ERC-1155 standard. Specifically, the onERC1155Received and onERC1155BatchReceived functions do not revert when they reject a transfer. According to the ERC-1155 standard, these functions MUST revert if they reject a transfer.
This may have been a deliberate choice by the authors given the comments in the functions' documentation, but ERC-1155 adherence is specifically listed as an invariant and this behaviour represents strict non-conformity.

Proof of Concept

This could lead to a potential loss of funds if an external IERC1155 contract is improperly implemented and doesn't check for the return value of onERC1155Received. In such a case, a user could unknowingly transfer tokens to the Ocean contract without a proper interaction. Since the Ocean contract doesn't revert the transaction, the tokens would be transferred successfully, but without the required interaction to credit them to the user in the ocean. This could lead to the tokens being stuck in the Ocean contract, resulting in a loss of funds for the user.

Tools Used

Manual inspection

Recommended Mitigation Steps

To ensure full compliance with the ERC-1155 standard, modify the onERC1155Received and onERC1155BatchReceived functions to revert when a transfer is rejected. This can be achieved by replacing the return 0; statement with a revert statement.

Assessed type

Other

@c4-bot-10 c4-bot-10 added 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value bug Something isn't working labels Dec 8, 2023
c4-bot-10 added a commit that referenced this issue Dec 8, 2023
@c4-pre-sort
Copy link

raymondfam marked the issue as insufficient quality report

@c4-pre-sort c4-pre-sort added the insufficient quality report This report is not of sufficient quality label Dec 10, 2023
@c4-pre-sort
Copy link

raymondfam marked the issue as duplicate of #218

@c4-judge
Copy link
Contributor

0xA5DF marked the issue as not a duplicate

@c4-judge c4-judge added the primary issue Highest quality submission among a set of duplicates label Dec 14, 2023
@c4-judge
Copy link
Contributor

0xA5DF marked the issue as primary issue

@c4-judge c4-judge added downgraded by judge Judge downgraded the risk level of this issue QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax and removed 2 (Med Risk) Assets not at direct risk, but function/availability of the protocol could be impacted or leak value labels Dec 15, 2023
@c4-judge
Copy link
Contributor

0xA5DF changed the severity to QA (Quality Assurance)

@0xA5DF
Copy link

0xA5DF commented Dec 15, 2023

This could lead to a potential loss of funds if an external IERC1155 contract is improperly implemented and doesn't check for the return value of onERC1155Received. In such a case, a user could unknowingly transfer tokens to the Ocean contract without a proper interaction.

This is a loss of funds due to a mistake on the user's side.
Marking as low

@0xA5DF 0xA5DF mentioned this issue Dec 16, 2023
@0xA5DF
Copy link

0xA5DF commented Dec 16, 2023

Moved to #336

@c4-judge
Copy link
Contributor

0xA5DF marked the issue as grade-c

@c4-judge c4-judge added grade-c unsatisfactory does not satisfy C4 submission criteria; not eligible for awards labels Dec 16, 2023
@c4-judge c4-judge reopened this Dec 20, 2023
@c4-judge
Copy link
Contributor

0xA5DF marked the issue as grade-a

@c4-judge c4-judge added grade-a and removed grade-c unsatisfactory does not satisfy C4 submission criteria; not eligible for awards labels Dec 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working downgraded by judge Judge downgraded the risk level of this issue grade-a insufficient quality report This report is not of sufficient quality primary issue Highest quality submission among a set of duplicates QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
Projects
None yet
Development

No branches or pull requests

4 participants