📥 Download Hardened JS Security Report
This summer, the Agoric and MetaMask teams kicked off the first-ever collaborative bug hunting exercise focused on a deep examination of hardened JavaScript, the foundation of Agoric smart contracts. This vulnerability discovery effort exercised the security properties of a lockdown shim maintained by Agoric that emulates hardened JavaScript.
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
For the purposes of this security engagement, the MetaMask reviewers focused on challenging the security properties of hardened JavaScript with an emphasis on surfacing escapes from Compartment code. The reviewers also focused on ensuring that Compartment code could not grant access to powerful platform capabilities (unless endowed), could not grant privilege to observe runtime, and could not engage in unauthorized communication with other compartments.
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,
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.
Ultimately, the MetaMask reviewers did not surface any Compartment escapes, and found the shim to be written with extraordinary care and expertise. It seemed clear to the reviewers that the shim’s lockdown functionality provides significant improvement to the safety of written JavaScript, and additionally, they found that the Compartment API brought a compelling interface for safe confinement of code.
Moving Toward a “Hardened JavaScript” Future
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?
During the engagement, one notable shift in perspective emerged that could not be classified or captured as an issue: the reviewers began to refer to the SES code as “hardened JavaScript.” Because the Agoric and MetaMask teams saw the code in a new light during their intensive review process, their focus shifted towards a more thorough understanding of the benefits of the lockdown capabilities for users.
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.
Though vulnerability assessments provide important insight into the security of code they target, these assessments are just one of the many components necessary to build a comprehensive security program that raises the cost of an attack for an attacker. To learn more about the security of hardened JavaScript and the code changes that emerged from our bug finding mission with MetaMask, read the full report here. And stay tuned to our blog for more Purple Team engagements from Agoric and friends.
Thanks for reading. You can join the Agoric community on Twitter, Discord, Telegram, and LinkedIn, subscribe to our monthly newsletter, and catch us at upcoming events.
