ECMAScripts tests regarding SES

Mark S. Miller erights at
Wed May 18 16:10:07 PDT 2011

[+ankur, joe, arjun, shriram, ulfar, mitchell, shap]

On Wed, May 18, 2011 at 1:54 PM, David Bruant <david.bruant at> wrote:

>  Hi,
> This message regards Secure ECMAScript (SES) [1] (by the way, can links
> like [2], [3] or [4] be added to the ses wiki page?).

Good suggestion. I will do so. For your [4], SES development has moved to <>.
I will update the wiki and the es-lab site to make that clear. I may not get
to either until after the May meeting.

> SES requires initSES.js to run. An environment where this happens is called
> "Secureable EcmaScript 5" (please correct if I misunderstand or misuse the
> terminology).

Ideally that would be right, and we hope will be right once browsers come
into more complete ES5 conformance. The current SES development includes
various so-called "kludge switches". From <

  /////////////// KLUDGE SWITCHES ///////////////


  // The following are only the minimal kludges needed for the current

  // Firefox, Safari, or the current Chrome Beta. At the time of

  // this writing, these are Firefox 4.0, Safari 5.0.4 (5533.20.27)

  // and Chrome 12.0.742.12 dev

  // As these move forward, kludges can be removed until we simply

  // rely on ES5.

Each kludge switch indicates whether it preserves SES safety. For example,
the first is:

>   /**

   * Workaround for


   * <p>This kludge is safety preserving.


   * <p>TODO(erights): Turning on this kludge is expensive, so we

   * should auto-detect at initialization time whether we need to on

   * this platform.




> Regarding Securable ECMAScript 5, are there particular aspects of ES5 that
> would need to be tested in order to make sure not only that initSES.js runs
> but also does what is expected from it.

Yes, absolutely.

> In other words, are there tests that could be added to Test262 in order to
> help ensuring an ES5 implementation is securable with "very high"
> confidence? Or is the current test suite sufficient?

The current test suite is not sufficient. Regarding which tests to add, a
good place to start is to look at the kludge-switch doc-comments in initSES,
especially those in es5shim.js. But there are a large number of other issues
I've been planning to write down and turn into tests. (I've been making some
progress on these in Sputnik CLs, some of which I have yet to commit.)

*More eyeballs would help here! *Please read the SES sources and Ankur's
paper at <> which
captures the reasoning and claims about SES's security, and try to spot any
assumptions we're making that are not adequately tested by test262.
Especially those that might be violated by some current implementations.

<> causes a huge
workaround in WeakMap.js but is documented only in a doc-comment in
WeakMap.js not associated with a kludge switch, because I didn't want to
include both versions in initSES.js. However, the current workaround is not
safety preserving for reasons documented there (the identity stealing

This all brings up another maintenance issue not specific to SES. For each
spec non-conformance, it would be nice to have a site, not necessarily the
"official" test262 site, where it was easy to gather associations between
failing tests and the corresponding bug threads of associated with the
various major JS engines that have publicly accessible issue trackers. In
particular, it would help answer the two questions: Are there any failing
tests without corresponding open bugs? And are there any open bugs not
demonstrated by corresponding failing tests?

Even on a perfect Securable ES5 system, the kludge
would still be necessary because the bug here is in the ES5 spec, not in the
implementations. In fact, AFAICT, all implementations correctly implement
this part of the spec, and so faithfully create the vulnerability that the
spec demands.

This case is interesting because, even though there have been two world
class efforts to formalize JS and do automated verification of security
properties, where both of these efforts have poured over the ES3 and ES5
specs as a reference, and had real browsers to test against, that both these
efforts missed this vulnerability. In fact, I am not aware of any previous
JS security work that even noticed the issue. This should *NOT* be taken as
a criticism of these efforts. It's just an important lesson in the kinds of
confidence we should and should not derive from the existence even of a
machine checked proof of security.

> David
> [1]
> [2]
> [3]
> [4]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list