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

Do security audit of the smart contract #1

Open
vporton opened this issue Mar 13, 2020 · 14 comments
Open

Do security audit of the smart contract #1

vporton opened this issue Mar 13, 2020 · 14 comments

Comments

@vporton
Copy link
Owner

vporton commented Mar 13, 2020

Do a security audit of this Solidity smart contract:

https://github.com/vporton/courts/blob/master/contracts/RewardCourts.sol

Apply only if you have security audit experience.

@vporton vporton changed the title Do security audit Do security audit of the smart contract Mar 16, 2020
@gitcoinbot
Copy link

Issue Status: 1. Open 2. Started 3. Submitted 4. Done


This issue now has a funding of 0.799 ETH (90.03 USD @ $112.68/ETH) attached to it as part of the vporton fund.

@gitcoinbot
Copy link

gitcoinbot commented Mar 16, 2020

Issue Status: 1. Open 2. Started 3. Submitted 4. Done


Work has been started.

These users each claimed they can complete the work by 3 weeks, 3 days from now.
Please review their action plans below:

1) ridesolo has been approved to start work.

hello, I'm an expert solidity auditor and I'm interested to audit your contract, you can check all my reports in my gist http://gist.github.com/ridesolo/. I have audited hundreds of projects the lasts two years.
Also I like to take my time to do a good work so hope you are not in a hurry.

Learn more on the Gitcoin Issue Details page.

@gitcoinbot
Copy link

@RideSolo Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!

  • reminder (3 days)
  • escalation to mods (6 days)

Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days

@RideSolo
Copy link

Working on it.

@gitcoinbot
Copy link

Issue Status: 1. Open 2. Started 3. Submitted 4. Done


Work for 0.799 ETH (93.56 USD @ $117.09/ETH) has been submitted by:

  1. @ridesolo

@vporton please take a look at the submitted work:


@vporton
Copy link
Owner Author

vporton commented Mar 22, 2020

My response to your security audit: https://gist.github.com/vporton/e39a060986d02e1889aea0b50aa4356c - please respond back.

@RideSolo
Copy link

RideSolo commented Mar 22, 2020

@vporton

i Index

For i index you are right when you say "i represent the position in the _trustees list which are courts to untrust" but the error is here:

trustedCourtsList[_truster][i] = trustedCourtsList[_truster][--max]; 

you are setting the last element at index i, but i does not represent the index of the court to be removed, it represent its position in _trustees array (not the position in trustedCourtsList array).

createIntercourtToken

As I commented "No owner is constrained to follow the id returned by createIntercourtToken", meaning that you didn't implement any mechanism to block owners from using the same intercourt token id. The function does return a unique id at each call, but any owner can use the same id.

Trusted courts

This is not a programing error, If you intended it to be like this then it is all right, I wanted to highlight the risks taken when implementing such logic.

Please note that as a general remark, I always try to stay neutral when I conduct an audit, I try to highlights the risks for both project team and users.

@vporton
Copy link
Owner Author

vporton commented Mar 22, 2020

Why have you removed this?

        if (_interfaceId == INTERFACE_SIGNATURE_ERC165 ||
             _interfaceId == INTERFACE_SIGNATURE_ERC1155) {
          return true;
        }

You proposed to add checks for methods, but removed the check for these two interfaces.

I do not understand.

@vporton
Copy link
Owner Author

vporton commented Mar 22, 2020

Could you provide the full code for setSupportedInterfaces()/supportsInterface()?

Note that the last version of the contract added two more public variables, which are also to be counted.

@vporton
Copy link
Owner Author

vporton commented Mar 22, 2020

I do not understand why you suggest to rewrite

    function supportsInterface(bytes4 _interfaceId)
    public
    view
    returns (bool) {
        if (_interfaceId == INTERFACE_SIGNATURE_ERC165 ||
            _interfaceId == INTERFACE_SIGNATURE_ERC1155) {
          return true;
        }

        return false;
    }

in another way. You tell something about gas, but it's obvious that this function uses very little gas.

@RideSolo
Copy link

RideSolo commented Mar 22, 2020

@vporton sure like this it is too low, however I saw that you commented out part of the value here, I set this issue to low, since If you wanted to list all the functions following ERC-165, the required gas to execute the function will be too high (probably higher than 10k or 30k suggested by the standards).

This is an audit, the recommendation done was to implement a more efficient way to list the functions, as commented " list all public function here, following the previous example" you can simply add the remaining functions by following the same example. The proposed implementation is more gas efficient since you can list as many function selectors as you want.

Also there was an error, since you set another function selector to true that must not be implemented, this is why I suggested a new way to implement it. as you can see the original code below.

    function supportsInterface(bytes4 _interfaceId)
    public
    view
    returns (bool) {
        if (_interfaceId == INTERFACE_SIGNATURE_ERC165 ||
            _interfaceId == INTERFACE_SIGNATURE_ERC1155 ||
            _interfaceId == INTERFACE_SIGNATURE_URI) {
          return true;
        }

        return false;
    }

Please note that it was just a suggestion and you can decide to ignore it. the main point was to point out the issue in case of setting more function selectors.

@vporton
Copy link
Owner Author

vporton commented Mar 23, 2020

Why should I add "all functions"?

INTERFACE_SIGNATURE_ERC165 and INTERFACE_SIGNATURE_ERC1155 are already checked. I am confused.

@RideSolo
Copy link

RideSolo commented Mar 23, 2020

I agree, I pointed this issue out because I saw you comments here I figured out that you wanted to implement all functions and using condition while accessing all global variables won't be optimal. also you should note that it is a low severity issue and it does not represent any risk .

@gitcoinbot
Copy link

Issue Status: 1. Open 2. Started 3. Submitted 4. Done


The funding of 0.799 ETH (93.56 USD @ $117.09/ETH) attached to this issue has been approved & issued to @RideSolo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants