ECMAScripts tests regarding SES
[+ankur, joe, arjun, shriram, ulfar, mitchell, shap]
On Wed, May 18, 2011 at 1:54 PM, David Bruant <david.bruant at labri.fr> wrote:
Hi,
This message 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 < code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses>.
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 < code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/es5shim.js#33
:
/////////////// 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 bugs.webkit.org/show_bug.cgi?id=55537
-
<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.
*/
//var TOLERATE_MISSING_CALLEE_DESCRIPTOR = false;
var TOLERATE_MISSING_CALLEE_DESCRIPTOR = true;
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 www-cs-students.stanford.edu/~ataly/Papers/sp11.pdf 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. Thanks!
bugzilla.mozilla.org/show_bug.cgi?id=637994 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 attack).
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 switch PATCH_MUTABLE_FROZEN_DATE_PROTO at < code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/es5shim.js#111>
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.
This message Secure ECMAScript (SES) [1] (by the way, can links like [2], [3] or [4] be added to the ses wiki page?). 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). 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. 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?
David
[1] ses:ses [2] code.google.com/p/es-lab/wiki/SecureEcmaScript [3] code.google.com/p/es-lab/wiki/SecureableES5 [4] code.google.com/p/es-lab/source/browse/trunk/src/ses