Anyone who's studied NTSB reports knows this is almost always how they go; a single failure that is no problem becomes one because of some other issue that doesn't normally happen, or couldn't happen because normally a third thing is always done ...

Same with tons of security incidents in general. It's the "swiss cheese model" (https://en.wikipedia.org/wiki/Swiss_cheese_model).

And when it becomes organisationally normalised that one layer of safety isn't working and the remaining ones are relied upon, then that's more like the subject of Normal Accidents [1]

[1]: https://en.wikipedia.org/wiki/Normal_Accidents

There are several very interesting books about this, yes. Air disasters are fascinating to read about.

A series of very good, detailed article about air disasters over on Reddit: https://www.reddit.com/r/AdmiralCloudberg/comments/e6n80m/pl...

Stable systems don't break because something went wrong, they break because everything went wrong.

I'm not completely sure the mechanics of this exploit, but I've recently adopted the personal guideline of "all enums and integer IDs start at 1", and 0 is simply an invalid value.

Not a hard and fast rule, and not something that will catch tons of problems, but now and again it does help me catch an uninitialized value.

> "all enums and integer IDs start at 1"

then whoever takes over maintenance from you and wants to make improvements says "hey, we can add this new v2 feature through the 0x0 which is available for future enhancements"

Unlikely. The way it works is you define your enums like this:

  enum class Color {
    Invalid, // Not a valid value.
    Red,
    Orange,
    Yellow,
    Green,
  };

I think if someone's crazy enough to reclaim a 0 value in an enum or integer ID, then they're probably going to do a lot of damage to the code no matter what you do.

Yeah, pretty much every integer enum I write has `UNKNOWN` or `INVALID` as the zero value. It adds either a `case` or a `default` to every switch and a clause or a `_` to every `match`, but it saves my ass even in non-security-sensitive settings.

That wouldn’t work in situations like this unfortunately. In the ethereum ecosystem the 0x0 address has a special meaning because it is used as the origin of things on chain when they are newly created (they are transferred from 0x0) and often also the destination of things when you want to destroy them (you “burn” something by transferring it to 0x0).

Fun part is as far as I understand this is just a convention and there is nothing intrinsic to 0x0 that makes it different from any other destination address. If someone was to find the private key for which 0x0 is the public half they would have access to a vast amount of stuff that has been transferred there over time. Finding this key is computationally unfeasible however.

Why wouldn’t it work here? Couldn’t you just as easily use address 1 or all ones for the same purpose?

Or use bigger numbers, so enums that get mixed up somehow won’t work.

> routine upgrade

yes, a routine upgrade. that's what it was..... (→_→)

The cofounder was involved in some drama with a CELO bridge not too long ago

https://imgur.com/a/gV6s1Gw

... that he also founded and planned to spin out with Celo, yes. James is the inventor of Optics, the cross-chain communication technique Nomad uses.

Very unhappy with how Celo handled the situation, as was much of the technical crypto community at the time.

Oh interesting! Seems like some heavy gaslighting by Celo then