I agree with @lastmjs that this (just the potential of a wasm jail-break)is a significant serious security issue for EXISTING dapps on IC.
For example :
The NFT Cronic Critters have an average value of about 10 icp for about 600 odd critters today based on sale listing after removing the ridiculously priced critters from the average calculation. There are roughly 5000 critters currently in existence. These are worth 5000x10 = 50,000 icp. At current approx $60/ICP , this is roughly $3M USD at risk in ONE nft type. Isolating canister executing in a sandbox would substantially reduce the risk; even if there are no known instances of WASM jail breaks.
It will only take one successful jail-break to completely erase trust from the community that we have tried, so assiduously, to cultivate. I would anticipate that TODAY we have close to $30 m in just NFT assets that are under risk. This estimate is based on the ROM of 10 different NFTs that are estimated to be on the IC today.
While arguments could be made to say that we have never seen an jail-break successfully occur in the wild, the amount of money is sufficiently large that it will attract hackers. I would think that securing canister execution should BE AT THE TOP of the priorities.
Thanks for the analysis! I guess one could rephrase your post as “there is a community driven bug hunting bounty program in place, with a bounty of ul to 30M$. As of today, the bounty was not claimed, which is a testament of how secure the IC is”
(Oh, and BTW, your browser runs untrusted Wasm in process. If someone has a jailbreak for the Wasm sandbox, at least if it also works in browser, they can get much more there, I assume.)
I feel like the honeypots created by canisters are much larger than you would find by breaking out of the Wasm sandbox in most web apps (the web app is just the frontend, not the actual server where a bank account is managed). And each application (tab) in the browser has a Wasm sandbox, and that sandbox is also sandboxed within its own process. We’re pointing out that the IC does not meet the standard of the browser. If all of your tabs and domains shared the same process, that would be more equivalent.
It’s also only been a few months since the value inside of canisters started accruing, so not much time to feel too comfortable.
I think it comes down to this: there is an obvious vulnerability with an obvious solution, and we should make implementing that solution a priority.
I’ve voted no on this proposal mostly to make a point about security. If there is an obvious vulnerability that could lead to catastrophe, and an obvious solution, I think the priority should be to patch that vulnerability.
I would like to see canister sandboxing per process before deploying these features.
It nearly did make it it’s post. (“An inadvertent community driven bug hunting bounty program for IC”). I will articulate why I did not make it it’s own post with all the rationale here (as opposed to a provocative new post).
At first, an free airdrop doesn’t really cost end users any real money. As the NFTs begin to percolate the eco-system, people begin to pay real currency for acquiring NFTs. For example, i got a free nft (starverse) for my participation on dscvr.one. At the beginning, on the entrepot.app, the lowest price of one of those nfts was around 0.8 icp. Currently the lowest price is 1.89. Doubling of the price from nothing. This begins to cause a sense of entitlement (“it’s mine…I own it”) for the average end-user. Imagine if they log into the account one fine day and they don’t see that NFT. This causes anger, fury etc. They will begin to blame someone else (nobody buys the argument…“but it was beta”). They have lost something of value.
All participants do understand that crypto is inherently risky. But they also expect that reasonable protection be afforded to them on any platform. An ICAntagonist can make significant noise. i.e. " oh that dfinity foundation…200 cryptographers…and they FORGOT to put in basic sandboxing that WE have known for years…". Unfortunately logic (the fact that we have it in the roadmap) cross raw emotion and logic, in that case, has no chance. It can cause a catastrophic cascade with the right shills.
The reason that my articulation is here as opposed to top level is that most people will not bother to read a post 50 levels buried. But concerned discerning teams will… and hopefully take action as appropriate.
I think it is worrying to surface, but more so confirming, these things on a forum level completely in the open. It only takes one person to forward this in the wrong direction and then you have the avalanche started with antagonist shill to tackle in the future. Not to mention that you openly confirm where the security risks are, for someone with bad intentions will just go straight ahead to try to utilise. Some parts should not be surfaced/confirmed in this way I strongly believe.
If this proposal will allow for the IC to make outbound connections to the Bitcoin network, can we leverage that same technology (however it’s implemented) to make outbound connections to arbitrary external services?
I’m guessing some kind of oracle will be part of this proposal’s implementation.
Not a random, but a good question. The answer is YES! Although not immediately available. One part of this integration is the network module that is added to the IC. This will be used for eth integration but also to do outside calls. This primer explain the integration in more detail: Integrating the Internet Computer and Bitcoin Networks | E001 - YouTube I also pasted a slide from that video overview that shows the added components.
I understand what you mean, but from where I stand I could not say what course of action to take even when given this knowledge (would you?), but those with ill intentions will just dive into and dig straight at the source where there also might be other security risks in the proximity to the surfaced one that has not been identified to utilise this as entry vectors as well. Where there are one security risk there might just be other ones lurking around. In some aspects, certainly when it comes to security risks, I don’t think the community as a whole is equipped to make a decision around this.
Everyone wants more information on IC-530. My suspicion is that HTTP calls are OK here because the messages being sent are signed, nonrepeatable, and a sure to be broadcast and included by anyone seeking financial award. I have some reservations that other kinds of http requests(say hitting an aws api) would have the same kinds of guarantees. I’m excited to hear more though in case they have cracked the determinism problem.
If I were a NFT buyer, putting down 188 icp for buying one NFT, I would like to make sure that my investment is secure. This information might make me insecure… therefore the concrete action that I take is NOT to spend 188 ICP.