6

Specifically, with my question I want to target Oracelize.it as arguably the most "state of the art" oracle service. This specification is done in order to exclude trivial attacks in the potential answer.

2

One potential attack vector is on the OraclizeAddrResolver. Essentially, Oraclize stores, on the Blockchain, the address of their latest Oracle contract. They also contain the power to change this address. An attacker, which could be Oraclize.it or someone who compromises their server, could trivially attack anyone using Oraclize by updating the Oracle address to the address of a malicious contract.

  • The OraclizeAddrResolver contract is owned by a special multisig contract where 3+ different keys need to sign for an OraclizeConnector update to happen, at least 2 of them need to be part of a subset of 4 special keys. Those keys are kept offline w/ security in mind (not on our servers). Even with Oraclize being the attacker, the attack surface is minimal: the oraclizeAPI helpers check for our fee not to be >1 ETH (this is the max we could steal from each Oraclize based contract) + everything we do is permanently stored on the blockchain for full transparency (our reputation would be broken). – Thomas Bertani Jul 21 '16 at 17:15
  • This reads like you could steal <= 1 ETH per call, not per contract??? raw.githubusercontent.com/oraclize/ethereum-api/master/… Not to mention it throws in a multiplier of tx.gasprice as well, which is user-defined, so you can set that as high as you like, at the cost of giving the miner of the exploit transaction (which could be yourself) a generous tip. – Edmund Edgar Dec 21 '16 at 0:34
2

There are lots of ways you could go at an oracle service but if contracts are working on the Oraclize model where you're just taking data from some other website, the other option is to attack that website instead. When you build an oracle service you have some idea of the kind of target it could become so you can at least try to secure it appropriately. Whereas if you're running a weather data feed it probably doesn't cross your mind that people will potentially be using it to direct significant amounts of anonymous online cash.

The danger here doesn't even stop at the site that gets attacked, because once one feed gets attacked the other ones are going to start revoking API keys and bolting down their terms of service rather than go to the trouble and expense of making them secure enough for these purposes, and people relying on their results to settle their contracts are going to be SOL. This is one of the reasons why we designed Reality Keys with a potential layer of human intervention between the original data feed and the contract, rather than just saying "Here's what the data source told us, good luck".

  • Very good points, however I think they need further discussion. On the Oraclize model you specify a datasource (ds) and a relevant formula. The one you are specifically referring to is the URL one. A ds can potentially be any, even a human moderator or Reality Keys itself! When talking about external data, some trustlines are inherently open as data is ultimately created by somebody you trust - our model wants to reduce them to the ds only. In order to avoid any issue, it's a good practise to rely on more than one with Oraclize being just the reliable carrier intermediating the data exchange. – Thomas Bertani Jul 21 '16 at 17:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.