Skip to content
This repository has been archived by the owner on Jul 9, 2021. It is now read-only.

Remove SignatureType.Caller #1015

Merged
merged 8 commits into from
Aug 24, 2018

Conversation

abandeali1
Copy link
Member

Description

Testing instructions

Types of changes

Checklist:

  • Prefix PR title with [WIP] if necessary.
  • Prefix PR title with bracketed package name(s) corresponding to the changed package(s). For example: [sol-cov] Fixed bug.
  • Add tests to cover changes as needed.
  • Update documentation as needed.
  • Add new entries to the relevant CHANGELOG.jsons.

@abandeali1 abandeali1 requested review from hysz and recmo August 24, 2018 17:01
),
"INVALID_SIGNATURE"
);
if (signerAddress != msg.sender) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How will this interact with executeTransaction? Seems like currently the exchange contract can become a valid signer for anything.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to add a require(msg.sender != this) here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not an issue since we are using DELEGATECALL and are not otherwise making arbitrary self-calls.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this mean that if I call executeTransaction and then call preSign that I could presign orders for the Exchange contract?

I recommend to not allow adding pre signed signatures if signerAddress == msg.sender.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

executeTransaction uses delegatecall, so the Exchange contract should never be msg.sender.

We've basically determined that usage of msg.sender here should be safe (this is a pretty common pattern). If we were using getCurrentContextAddress, there would definitely be extra protections.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no direct vulnerability in the 0x protocol relating to this change. A scenario where an entity creates a smart contract that has a token balance and has approved the AssetProxies could still be vulnerable if they allow forward calls to the exchange contract and the function preSign is callable. It's acknowledged that this is outside of the control of 0x and for that reason the issue is considered closed.

I still recommend caution around the assumption that no signature validation needs to be performed when msg.sender == signerAddress.

),
"INVALID_SIGNATURE"
);
if (signerAddress != msg.sender) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not an issue since we are using DELEGATECALL and are not otherwise making arbitrary self-calls.

@abandeali1 abandeali1 force-pushed the feature/contracts/removeCallerSigType branch from 951e219 to ad0e4fe Compare August 24, 2018 20:11
@abandeali1 abandeali1 force-pushed the feature/contracts/removeCallerSigType branch from 1397b04 to 0629a7d Compare August 24, 2018 21:48
@abandeali1 abandeali1 merged commit 82b51db into development Aug 24, 2018
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.006%) to 85.896% when pulling 0629a7d on feature/contracts/removeCallerSigType into 7351bf0 on development.

@abandeali1 abandeali1 deleted the feature/contracts/removeCallerSigType branch August 28, 2018 05:02
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants