Today, the Agoric team is excited to share the results of that informal, collaborative vulnerability assessment here. A proposal to make this experimental draft implementation an official language feature is currently a Stage 1 proposal to the ECMA TC39 committee.
Red + Blue = Purple
During the engagement, the MetaMask Team (with the addition of Mathieu Hofman of Agoric) took on the offensive posture of a Red Team, and Agoric’s module maintainers took on the defensive posture of a Blue Team. Typically, a vulnerability assessment of this type might be referred to as a red team/blue team exercise — but while this framing may work well for military exercises and scrimmages, it can have unintended consequences for application security reviews. If highly motivated red and blue teams are too focused on defeating one another, they can lose sight of what’s most important at the end of the day: working together to protect people who use the software they aim to secure.
In lieu of going head-to-head in a battle, all participants engaged in Purple Team techniques that included sharing deep insights into the knowledge and workings of the code, collaborative line-by-line code reviews, and adversarial testing driven by the knowledge and insights shared by both teams. By combining forces and perspective on mitigation and remediation of issues, the Agoric and MetaMask teams engaged in a deeper, more thorough examination of the code than a traditional Red/Blue engagement would have enabled.
Findings: No Critical Vulnerabilities
Within the scope of this assessment,
- No critical vulnerabilities were surfaced by the reviewers. The majority of the issues surfaced were rated as “Informational” or “Low” Severity findings, and the security model and architecture of the code was not broken. While one known security issue involving the use of domains on node does exist, this avoidable issue only impacts node under specific conditions.
- The majority of issues surfaced were classified as either a code change, a documentation change, or test development. The mitigations and remediations that emerged as a result of this assessment yielded improvements in the the defenses, usability, and observability of the code. There were no major changes made to the architecture of the shim.
- A new, unanticipated attack vector emerged in the scope proxy handler. During the engagement, a low severity finding nicknamed the ‘has hazard’ was surfaced by Mathieu Hofman. While the issue does point to a vulnerable condition in the code, this vulnerability is not exploitable.
When it comes to security assessments, a good one can provide important insight on application security, but a great one can be transformative in how a team thinks about the code it builds, maintains, or consumes. In previous iterations of the shim, there was a strong emphasis on its capabilities to deliver “secure” ECMAScript. But “secure” can be an ambiguous descriptor — what was the shim code secure against? And what benefits does that security confer to someone using the shim code?
This joint effort to discover security bugs was more than just a great way to get two friendly teams together to jam on code. The intelligence shared among code maintainers, code consumers, and code breakers was invaluable in gaining an entirely new perspective that will continuously improve the security and resilience of their code.