Why and how does the "low security" functions affect the biggest multi signature contract?

Question

People use this contract everyday http://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol and it's also the contract with most ethereums right now.

Also you can create a multisig account on the official Ethereum Wallet using this contract source code.

But then when I go inside the site https://etherscan.io/address/0xab7c74abc0c4d48d1bdad5dcb26153fc8780f83e#code we have all these warnings stating that low security

Warning: The compiled contract might be susceptible to ZeroFunctionSelector (very low-severity), DelegateCallReturnValue (low-severity), ECRecoverMalformedInput (medium-severity), SkipEmptyStringLiteral (low-severity), IdentityPrecompileReturnIgnored (low-severity), HighOrderByteCleanStorage (high-severity), SendFailsForZeroEther (low-severity), DynamicAllocationInfiniteLoop (low-severity), CleanBytesHigherOrderBits (medium/high-severity) Solidity compiler bugs.

How should I as a investor (and a programmer that has not fully learned Solidity) use this? Of course I have heard the Parity exploit which gave hackers freedom to just take 30 Milion USD.

My question is: Should I be worried? And what should I be careful with and pay attention to?

UPDATE:

I understand you but I can the basic solidity and I can't see any "internal" functions or "guards" which was put in action by parity after their exploit.

But here I have a more in depth analysis by the solidity remix simulator stating re-entrancy vulnerabilities: https://i.sstatic.net/hipr3.jpg

UPDATE 2:

You said higher compiler version is better well all of the contracts using that code (which I said is the one used in the Ethereum wallet) use version 0.3.2! 0.3.2! Which is from 2016!

Answer 1

The entire Ethereum ecosystem is in the beginning stages. Mistakes are to be expected, but they should of course not be tolerated if it involves large amounts of money.

There are basically two types of vulnerabilities that can allow funds to be stolen:

1. Programmer mistakes

   For example, the re-entrancy vulnerability used to be commonplace. Most DApp developers today are aware of this and will not make that mistake.

   Nowadays most mistakes are specific to the logic of a certain application. The only way you can be sure there aren't any is by formal verification, extensive code review and/or the test of time & money.

2. Compiler bugs

   These are mistakes made by the developers of Solidity compilers. They are practically impossible for DApp developers to detect or do anything about.

   Once a smart contract has been compiled with a bug and has been deployed on the blockchain, the bug stays. Contract deployment is final.

   It is important to note that just because a compiler has a bug, it does not at all mean that all contracts compiled with that compiler have a bug. Compilers bugs only have any negative effect in rare situations. (otherwise they would have been detected long ago, before the compiler version containing the bug was released)

You should not pay too much attention to all the warnings that etherscan.io gives. They simply look at which compiler version was used, and give a list of all known bugs for that compiler version. They don't actually do a deep analysis of every contract. Chances are, the contract you are looking at was not affected by those bugs.

It is a good idea to learn Solidity on at least a basic level, and just to read the code to see that no obvious errors were made. Errors like re-entrancy vulnerability are fairly easy to spot. Besides those, you should check for logic mistakes in the programming of the specific application you're looking at.

Some general tips:

• A higher compiler version is in general less risky.

• Contracts with reviewed source code are in general less risky.

• Shorter contracts are in general less risky.

• Contracts that have existed for a long time, have dealt with large amounts of money and have not been hacked are in general less risky.

Unfortunately, there are no guarantees to be made about all contracts.

I hope this helps somewhat.

Answer 2

This is a good answer by @Jesse Busman, but as you can see the solidity compiler states a possible re-entrancy vulnerability, however this is only through static analysis, and the compiler does not check for modifiers. Here is a re-entrancy vulnerable function, but one that is safe:

function reEnterMe(uint256 etherAmt) onlyOwner {
   if (balances[owner] >= etherAmt){
      owner.send(etherAmt);
      balances[owner] -= etherAmt;
   }
}

Since the contract sends ether BEFORE subtracting it from the balances[owner] mapping, this function is re-enterable.

However, the onlyOwner modifier prevents ANYONE except the owner calling this contract, or it will throw. Therefore, this function is relatively safe, because who would want to re-enter their own contract?