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

Unprotected Calls #49

Open
byakuren-hijiri opened this issue Jul 30, 2024 · 3 comments
Open

Unprotected Calls #49

byakuren-hijiri opened this issue Jul 30, 2024 · 3 comments
Assignees
Milestone

Comments

@byakuren-hijiri
Copy link
Contributor

In the following contract:

message Insert {
  key: Int;
  val: Int;
}

contract Foo {
  m: map<Int, Int>;

  receive(msg: Insert) {
    m.set(msg.key, msg.val);
  }
}

The access to m.set is available to anyone. Therefore, it is easy to disrupt the contract's behavior by implementing a DoS attack.

Another example includes an unprotected send call, which enables anyone to send messages from this contract.

The corrected version should contain some condition in the dataflow that checks some limitations or permissions to perform such a call.

@jubnzv jubnzv added this to the v0.2 milestone Aug 7, 2024
@jubnzv jubnzv modified the milestones: v0.2, v0.3 Aug 20, 2024
@jubnzv jubnzv modified the milestones: v0.3, v0.4 Sep 21, 2024
@jubnzv jubnzv self-assigned this Oct 12, 2024
@jubnzv
Copy link
Member

jubnzv commented Oct 19, 2024

It would be easier to implement if we had effects in the Callgraph: #189. For example, we should check if there is some kind of conditional workflow in functions that send or mutate the contract's state.

@jubnzv jubnzv modified the milestones: v0.5, v0.6 Oct 19, 2024
@jubnzv
Copy link
Member

jubnzv commented Oct 22, 2024

We should also track unprotected calls leading to cell overflow (#20), undeflow (#172) or runtime errors due to unexpected size (#114):

fun test(size: Int) {
  beginCell().storeInt(self.a, size) // Bad: triggers cell overflow or a runtime exception if size > 257
}

@jubnzv
Copy link
Member

jubnzv commented Oct 24, 2024

We could additionally describe unprotected selfdestruct (when SendDestroyIfZero is used in the unprotected send).

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

No branches or pull requests

2 participants