Purple Team Vulnerability Assessment of ERTP + Zoe

jessysaurusrex commented 2 years ago

As part of the process for launching mainnet 1, Agoric will be engaging in a fully remote, week-long collaborative bug hunt to assess the strengths and weaknesses of ERTP and Zoe, the digital asset standard and smart contract platform that ensure offer safety and rights conservation for users.

This exercise is open to members of the Agoric community! If you would like to participate in our code walkthroughs or bug hunting exercises, please email jessy@agoric.com. You can learn more about Purple Teaming and why Agoric favors a collaborative bug hunting approach in the first Purple Team Report on HardenedJS.

Over the next few months, there will be several more Purple Team engagements that include the RUN protocol, the kernel, governance, the wallet UI and smart contract, and a handful of other vital tools and components needed to power the economy and ecosystem.

🥅 Goals

To challenge the security promises of ERTP + Zoe, and (hopefully) gain additional confidence in the security of ERTP + Zoe by getting more eyes on the code.
To produce findings + artifacts that demonstrate our best efforts to challenge the code.
To add at least one additional defensive security tool or practice to our toolkit.

🗓Schedule: Jan 10-14, 2022

Monday: Opening Ceremonies + Code Walkthrough 9am PST - 12pm PST ; Breakout Sessions from 1pm - 3pm PST Tuesday: Code Walkthrough 9am PST - 12pm PST ; Breakout Sessions from 1pm - 3pm PST Wednesday: Bug Hunting 9:30am PST - 12pm PST ; Breakout Sessions from 1pm - 3pm PST, to allow for the monthly Agoric Community Call Thursday: Bug Hunting 9am PST - 12pm PST ; Breakout Sessions from 1pm - 3pm PST Friday: 9am PST - 12pm PST ; Closing Ceremonies from 1pm - 3pm PST

🏴‍☠️Teams

Deep cooperation between bug hunters and core maintainers is a key focus of Purple Teaming. By partnering and sharing intelligence with one another, the teams can more thoroughly evaluate the code than if they were competing against one another.

Red Team: @mhofman, @dckc, @gibson042, @b4d2 Blue Team: @erights, @Chris-Hibbert, @dtribble

🔬 Assessment Scope

The following repositories fall within the scope of this vulnerability assessment:

A commit hash will be available after Opening Ceremonies on 1/10/2022.

✅ In Scope

The Zoe that is under review during this assessment will be included in mainnet 1 launch is not the same Zoe that we will be using in later phases of mainnet launch. Any code and security properties contained in the ERTP + Zoe repositories that impact Mainnet 1 goals, with a focus on understanding Zoe’s vulnerability to malicious messages are in-scope for this engagement.

The "Fred Problem” is in scope.
Writing malicious contract code to exploit Zoe weaknesses is in scope, but any issues surfaced would be of a lower severity for the purposes of mainnet 1.
Using simple contracts (e.g. ~100 LoC) to examine risk partitioning and to ensure that no failure of code on the part of one seat enables it to impact another.
- Simplest long-lived smart contract relying on seats + user instances should be used as a tools to examine Zoe’s properties
Anything that makes it difficult for the wallet UI to operate safely/securely.

⛔️ Out of Scope

RUN protocol , which will be assessed by a Purple Team exercise in February.
The design elements of sample contracts, and any contracts used for testing.
Metering, as this feature has been removed from Zoe.

🏛 Security Promises + Invariants

If a deposit fails or hangs while a user is making an offer, the offer should not succeed. Any funds deposited should no longer be accessible to the user.
A malicious issuer should not be able to prevent access to brand or display information to cause a hang or failure.
Contract code must not be able to adversely affect the functioning of the Zoe Service or the Zoe Contract Facet though they run in the same vat.
Contract code should not have access to user assets held by Zoe’s escrow service.
Rights conservation and offer safety are enforced in the contract facet, and no contract should be able to violate either.
A user can only receive an invitation to a smart contract instance if zcf.MakeInvitation is called. No other contract code or channel can create an invitation for a contract instance.

The Attacker’s Guide to Zoe outlines security promises and identifies potential points of weakness in the code up for review, and is a key resource for participating in this exercise.

📚Documentation + Resources

🎬 Getting Started

This guide to Agoric’s JavaScript Programming includes Agoric-specific additions and deletions to general JavaScript programming that reviewers will need to be aware of.
The sections on Vats and Far() and Remotable objects are of note.
Communication between ERTP + Zoe happens asynchronously , and requires calling E(object).method(). As a result, message ordering is important when communicating across vats, especially for ERTP.

⚖️ ERTP

These resources should be helpful for navigating ERTP, Agoric’s token standard for digital assets that is written in JavaScript.

ERTP Guide
ERTP API
With ERTP, it is possible to create a wide range of digital assets that are transferred exactly the same way and that exhibit uniform security properties.
ERTP uses object capabilities to enforce access control. If your program has a reference to an object, it can call methods on that object. If it doesn’t have a reference, it can’t.
The assert , marshal , and notifier dependencies of the Agoric SDK are important for understanding ERTP.
In order to understand the fundamentals of ERTP, it is important to understand the workings of the code that it builds on. Before digging into the code, it is important for reviewers to become acquainted with Hardened JavaScript .
This Purple Team Report on Hardened JavaScript may also provide additional insights.

🧮 Zoe

Zoe is Agoric’s smart contract framework, which is built on ERTP. It can be used to run code on-chain, mint new digital assets, and credibly trade assets.

📝 Technical Presentations and Papers

Concurrency Among Strangers : Programming in E as Plan Coordination by Mark S. Miller, E. Dean Tribble, and Jonathan Shapiro
Reasoning about Risk and Trust in an Open World discusses the Purse system (an ancestor of ERTP) and the escrow exchange agent (ancestor of escrowing and atomic commit logic proportions of Zoe).
Talk by Mark Miller on Higher Order Smart Contracts across Chains/Distributed Secure Cross-chain Messages
Talk by Brian Warner on how Agoric mitigates eventual send/re-entrancy hazards
Distributed Electronic Rights in JavaScript discusses the workings of hardened JavaScript and Agoric’s distributed object model.

erights commented 2 years ago

Hi @jessysaurusrex great guide! One adjustment though:

Can an invitation be exchanged for BLD? If so, “the Fred problem” is in scope.

In the same sense that vulnerability to malicious contracts are in scope, even though they're not within the mainnet 1 threat model, I'd say the Fred problem is in scope regardless. Just like a vulnerability to a malicious contract is lower severity until we have malicious contracts, I'd say that a failure to solve the Fred problem is lower severity until invitations are tradable. Just like the rationale for the Zoe architecture cannot be understood without considering malicious contracts, the rationale also cannot be understood without considering the Fred problem. Further, a failure to solve the Fred problem will become high severity early in mainnet 2 at the latest, while malicious contracts won't be severe until mainnet 3.

erights commented 2 years ago

Some further detailed resources, which I expect to be both stale and incomplete. However, they are detailed enough to provoke thoughts about what invariants we rely on, and therefore what claims might be attacked:

https://github.com/Agoric/agoric-sdk/blob/master/packages/marshal/src/types.js

https://github.com/Agoric/agoric-sdk/blob/master/packages/marshal/docs/copyRecord-guarantees.md

https://github.com/Agoric/agoric-sdk/blob/master/packages/store/src/types.js

erights commented 2 years ago

Now that @jessysaurusrex created the audit-zestival label, I went and classified all the issues that looked potentially relevant:

https://github.com/Agoric/agoric-sdk/issues?q=is%3Aopen+label%3Aaudit-zestival+sort%3Aupdated-desc

jessysaurusrex commented 2 years ago

Thank you, @erights! Updated to clarify that the Fred Problem is in scope.

Is there a resource somewhere that explains the Fred Problem? I've encountered Fred in The Digital Path: Smart Contracts and the Third World in the Agoric Papers, but I didn't surface any explanations that could be pointed to in an audit report or blog post... just brief mentions across Github issues.

If something does not already exist, I can add creating a Fred Problem explainer to the list of things that should come out of our engagement this week.

Agoric / agoric-sdk