🧀 How many slices of Swiss cheese would the community like in their ckERC20 sandwich? Also, ICP Giveaway

[ckMood]

I think I want to specify my answer a bit more. I think the WASM hashes exclusively are the cheese. I think that’s the true answer.

[Kick1776]

Surprise! The easter egg is…there isnt one. You just REALLY wanted us to focus on this topic and it seems to be working lol

‘System Canister Payload’ = swiss cheese proposal “that all it does is feed the payload to an update call on the canister”

[Lorimer]

Good effort everyone who searched for the Easter Egg! I can confirm that nobody found it, though @ckMood came close with his mention of hashes.

The Easter Egg is located in this post on that thread. Expand the details section of that post (‘Here’s a slightly more detailed description of my concerns’). The hash that’s quoted in that section is intentionally inaccurate. It’s not the same as the hash for the WASM that the canister was running at the time (which can be verified by following the link that I provided right next to the disguised hash). The hashes look similar, but they’re not the same. The bold sections in the hash below highlight all the parts that were wrong.

• 658c5786cf89ce77a0bb3b17fe855c30f00171de0dc946cc463c9f19c348cb5e

This hash has been sitting there for over a week. It was able to hide in plane sight:

• despite attention being drawn to it (this topic has been top 2 on this forum for the last 2 days)
• despite readers being instructed to look for something out of the ordinary
• despite being offered financial reward
• and despite the hints.

This hash was able to hide so effectively because it looks practically identical to the human eye, and because nobody was expecting it to be different. It takes computational resources to get a hash to look very similar, but it’s certainly possible and a realistic danger if there’s money to be made.

This is my fear in a nutshell. Build verification isn’t necessary for these sorts of proposals. In my opinion this significantly increases the chances that a nefarious WASM may not get spotted if an attacker picks the right moment to submit a proposal (amidst a swarm of other similar proposals that are all legit).

Sure, verification tools can help. But this attack vector simply doesn’t need to be here for canister configuration updates. Dynamic dispatch could be used to allow a single NNS function to pass a config payload to an arbitrary update function on the canister (specified in the proposal).

If you’d like to see this attack vector removed please consider upvoting, sharing, and commenting on this thread to make it clear that you agree (if you’ve not done so already). If you disagree, please also share your opinion so that we can see the complete picture of community sentiment.

Thanks for taking part everybody!

[ckMood]

Good fun! I kinda think I found the cheese but it’s okay! Great way to showcase your point!

[zkcrypto_real]

@Lorimer

• 658c5786cf89ce77a0bb3b17fe855c30f00171de0dc946cc463c9f19c348cb5e

This hash has been sitting there for over a week. It was able to hide in plane sight:

• despite attention being drawn to it (this topic has been top 2 on this forum for the last 2 days)
• despite readers being instructed to look for something out of the ordinary
• despite being offered financial reward
• and despite the hints.

Sums up the whole purpose of this thread I guess

[Lorimer]

Thanks for being such a good sport @ckMood, you definitely came the closest. If you’d pointed out the specific hash and declared that it wasn’t consistent, you’d definitely have found the Easter Egg. Just to clarify, in this situation you would have been the protective layer of Swiss cheese, rather than the hash being the cheese

@bitdivine, you made some interesting points about formal verification and LLM tooling. Note that this specific attack vector is all about the hash (the nefarious code would not be visible).

[Lorimer]

Please consider casting your opinion about whether or not this attack vector is concerning (worth addressing / removing). If enough people are concerned, maybe then we can discuss a little bit more about how it can be addressed - I don’t think it would take much.

• In my opinion, this is a concerning attack vector
• In my opinion, this is not a concerning attack vector
• I don’t understand this attack vector

Thank you for your time

[jsull9]

So, before I go off on a tangent or rant giving a response… I’ll ask these initial questions…

1. Whose opinion matters here, or who will you not brush off? Just higher-level devs? Or do you want the opinion/ feedback of a “regular” neuron holder/voter? Even though the voting power is insignificant it doesn’t matter…

2. If you care about the nontechnical neuron holders, or the individual with little financial “skin in the game” What does this attack vector do? More specifically, if you were to, or someone else were to try and use this to communicate this issue to the regular neuron holders how would you describe the threat level? What are you suggesting a “normal voter” do?

I would suggest explaining this in very non-technical ways if you want to reach the smaller neuron holders.

@Lorimer

SCM proposals are designed to modify the WASM that a system canister is running (the change can be arbitrarily broad in scope, unlike a simple configuration update). The potential damage that can be caused by a bad actor who successfully manages to get an SCM proposal past the community is enormous.

Recall that a new ckERC20 token is just a configuration change to the Ledger Suite Orchestrator - there’s no need to modify the WASM. The proposal that enabled ckUSDC did not modify the WASM (see the canister upgrade history here and notice the unchanging hash for proposal 129750). On the other hand, note that the ckUSDC proposal itself states in the title “Upgrade Nns Canister: vxkom-oyaaa-aaaar-qafda-cai to wasm with hash: 658c5786cf89ce77e58b3c38e01259c9655e20d83caff346cb5e5719c348cb5e”. This is not at all what the proposal is essentially about - the WASM isn’t changed. This is the first sign that an SCM proposal (in its current form) isn’t the best fit for minor configuration updates to system canisters.

@Lorimer

As far as I understand, all it would take would be a well timed Trojan Horse, and some conditioned complacency and/or fatigue from voters (eyeballing the hashes, relying on uniformly randomly distributed hashes looking very different). This could lead to a very convincing looking SCM proposal (to make an expected minor configuration update to a single ledger suite) instead nefariously modifying the Orchestrator and seizing control over all ckERC20 ledger suites.

3. I like letting individuals who get paid bounties verify the hash and follow their neurons for this exact reason. However, I have a “mouthful”, I could say on this issue and others similar to it that probably highlight similar experiences of a collective group of “small neuron” holders. I’ll gladly give that feedback if you want. Otherwise… I mean kudos @ckMood for the quickdraw super close!

[Lorimer]

Whose opinion matters here

Everyone’s, it’s about gathering sentiment.

What does this attack vector do?

If successfully executed, allows an attacker to take control of the ckUSDC ledger and all other ckERC20 ledgers (drain funds etc.).

how would you describe the threat level?

The chances of someone pulling it off are low (though higher under plausible conditions). The damage that they can do if they pull it off is very high (described above).

What are you suggesting a “normal voter” do?

Cast your opinion in the poll, share it with others, discuss your concerns with others (if you find this concerning), ask DFINITY for more input about whether they do/don’t consider this to be a concern.

In my opinion there’s a very simple fix.

[Lorimer]

For anyone interested, this conversation has been progressed on another thread.

@jasonzhu

This is not currently supported . Honestly, I don’t know whether it’s possible or how difficult it is.

Thanks for your insights on this @jasonzhu, it’s been really helpful. It looks like this wouldn’t be the low hanging fruit that I initially expected. Do you know who the best point of contact for this would be in DFINITY? It seems like it would be a useful feature in general to allow a canister to be rebooted without needing to specify any new WASM at all.

[Lorimer]

@Pete

I largely agree with your suggestion. It would indeed be much cleaner if a proposal which only updates args and does not touch the wasm would not require a copy of the wasm to also be submitted.

There’s probably a few components which would need to be updated to make that change. Something for the team to definitely consider doing though.

Thanks @Pete