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

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.

1 Like

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”

1 Like

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.

:scream: 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!


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

1 Like

:rofl: :rofl: :rofl:

Sums up the whole purpose of this thread I guess


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 :wink:

@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).

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
0 voters

Thank you for your time :pray:

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.

  1. 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!

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. :slight_smile:

In my opinion there’s a very simple fix.


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

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.