IBC Emergency Button

Sup.

I wanted to take the time to discuss a new important feature we’re adding in the 1.9 upgrade - The IBC emergency button.

The point of this feature is that in the interconnected ecosystem, where funds can be passed between chains without permissions or limits in the event of a hack, we - as an ecosystem - may want the ability to contain a security event to give responders time for investigation and remediation.

One of the most important things you can do in case of a breach that causes (or can cause) a loss of funds is to contain the event. That means limit the attack surface and mobility (i.e. where they can go with their funds post-exploitation).

For example, imagine Osmosis is hacked. To try and “launder” the stolen tokens, the attacker may choose to transfer them to Secret Network, swap them on Blizzard to axelarETH and escape to some Mixer on Ethereum.

Another scenario is simply a bug in IBC - imagine a bug with the light-client where you could fake transfer of funds and mint them on another chain. If we cannot turn off IBC, we cannot stop exploitation (relayers are permissionless, so a sophisticated attacker can run their own relayer).

While decentralization is a core value of the network, we think that the ability to respond to ecosystem-critical events is important. That’s why we came up with the emergency stop button for IBC.
The emergency button feature is implemented as an IBC middleware, which can halt incoming and outgoing messages from any of our supported IBC stacks (transfer/compute/ICA/etc) for all IBC channels (basically all-or-nothing).

It contains two core attributes -

  1. The status of the switch: On/Off
  2. The admin that can toggle the switch

The admin is an address that is set by governance. It defaults to no address, so there has to be governance approval for the feature to be enabled.

The admin address can and should be a multisig, comprised of core network stakeholders across multiple time zones to ensure that there is always a response available. In the future, this address can also be used by a dedicated response team.

Lastly, the switch itself can also be toggled by governance, though this is more fitting for turning IBC back on after an event concluded.

While the emergency button can definitely be improved on, we think it’s a good first start in thinking about security in an interconnected blockchain space.

We wanted to take this chance to gather the community’s thoughts on this design, suggestions for improvement or general feedback.

Best,
Cash

6 Likes

Hey Cash,

I think the feature is an important backup mechanism to have in hand.
I would like it if it’s possible to also limit it to a perticular channel so that if a compromised network is reported we just shutdown this channel without affecting rest of the networks.
This can come in future upgrades but something like this will reduce the attack frameworks effects on the network.

3 Likes

If you just limit a channel to a supposed compromised network, what stops an attacker to re-route the funds via other networks (channels) to Secret etc.

2 Likes

I think both of these are valid points, and it depends on the specific situation.

Something like a bug could justify stopping a specific channel while a fix is deployed (for example, channels bound to secret contracts) if the impact isn’t too high. I think that having the ability to be able to control specific channels, ports (i.e. stopping transfers while allowing cross-chain contracts) and direction (halting just egress or ingress) would be a good tool to have, though we’d have to make sure that as @facelessman21 said - we don’t leave any backdoors open.

I think generally speaking, we’ll take this model to the IBC community at large and start a discussion on incident response. That way we can get a bigger picture of what the response across the ecosystem looks like, and how our response fits in

4 Likes

I shared this in a few Cosmos communities, and someone pointed out that Osmosis has an “IBC Rate Limit” feature with a similar purpose. What do you guys think about that solution? Seems like it allows transaction volume to be limited rather than disabling transactions completely.

We looked at their solution, though for us it has a few drawbacks:

  • The rate limit is a proactive security tool - i.e. the limits are set in prepartion for an attack. The emergency button is a reactive one - it’s a tool to allow response to an event. To that end, I think both tools can complement each other and they’re not mutually exclusive. That being said, I feel like it’s more important to have an emergency fail-safe in place that allows instant response times without reliance on governance in a worst-case scenario.
  • Implementing it is quite a bit more complex. That means more development time, more testing, and more places that can fail. Specifically from a performance standpoint a solution that requires all transfers to pass through a rate limiting smart-contract would introduce quite a bit of overhead.
  • We think that it will be difficult to set proactive limits in a way that balance damage control and usability - especially long term when liquidity, valuation and usage changes

For these reasons we felt that while rate limiting is a very useful tool (especially for a chain focusing on DEX use-cases) we wanted to start with something very basic and build from there

1 Like

You shouldn’t need this middleware. The IBC team did consider such a feature but the SDK team has implemented their own circuit breaker instead: feat: module circuit breaker by tac0turtle · Pull Request #14521 · cosmos/cosmos-sdk · GitHub

Although it is in the next SDK version as we speak, it is its own go.mod, so people should be able to use it in 0.47 and -.46. It works by blocking execution of a specified message (not just IBC messages)

1 Like