Incorrect result when accessing mapping of a remote contract

Description

I’ve ran into unexpected Mythril behavior which can be simplified to the following example. Consider the contract:

pragma solidity ^0.4.20;
contract Killable {
    mapping (uint => uint) map;
    function kill(uint key) public
    {
        map[key] = 1;
        if (map[0xdeadbeef] > 0) suicide(msg.sender);
    }
}

When deploying this contract (via ganache) and analyzing via the AccidentallyKillable module, the vulnerability is successfully detected:

Transaction Sequence:

Caller: [ATTACKER], function: kill(uint256), txdata: 0xd29a0025, value: 0x0
Caller: [ATTACKER], function: kill(uint256), txdata: 0xd29a002500000000000000000000000000000000000000000000000000000000deadbeef, value: 0x0

(although the first call seems unnecessary). However if we use a public mapping of another contract (rather than a local private one):

pragma solidity ^0.4.20;
contract RemoteMap {
    mapping (uint => uint) public map;
    function setVal(uint key, uint val) public
    {
        map[key] = val;
    }
}

pragma solidity ^0.4.20;
import "./remote_map_uint.sol";
contract Killable {
    RemoteMap constant remoteMap = RemoteMap(<address of RemoteMap>);
    function kill(uint key) public
    {
        remoteMap.setVal(key, 1);
        if (remoteMap.map(0xdeadbeef) > 0) suicide(msg.sender);
    }
}

and similarly analyze the latter contract on-chain, only the first “unnecessary” transaction is produced (which by itself does not cause a call to suicide):

Transaction Sequence:

Caller: [ATTACKER], function: kill(uint256), txdata: 0xd29a0025, value: 0x0

How to Reproduce

I deploy all contracts via ganache and analyze on-chain via myth analyze -m AccidentallyKillable --rpc localhost:8547 -a <address> I am on Mythril v0.22.30.

Expected behavior

I expected the call kill(0xdeadbeef) to be detected as a vulnerability in the second case as well.

Additional Environment or Context

I am not sure if this is the same problem as discussed in #1494 (symbolic storage locations). However it seems strange that analysis succeeds when the mapping is in local storage but fails when it is external to the contract. Additionally, analysis fails in the same way (prints transaction without any function argument) when analyzing from source or when --unconstrained-storage is specified (I thought this option would help circumvent the symbolic location issue).

[norhh]

@loki3451 , your local client is returning “0x” for storage information, which is invalid for json-rpc. I’ll handle this case.

[norhh]

@loki3451 , thanks for detecting this error, can you create a separate issue?