Builtins: Security problems with meta-objects proposal

[lth]

The basic assumption here is that namespaces (not restricted to "private") add access security; the meta-objects proposal itself supports this view because only public members may be iterated on NominalType objects. The meta-objects systems reveals many private facts, though. This is a list of known issues.

(1a) Consider:

  package P
  {
    internal namespace ns;
    ns class C {
      ns var p;
    }
    public function f() { return new C }
  }

A call to f yields a C object, to which typeOf can be applied. This yields an object with a name() method that returns a Name object; the qualifier of that name reveals ns.

(1b) If ns is internal then the internal namespace of a package can be stolen.

(2) The implementedBy method on InterfaceType reveals private classes throughout the system that implement interfaces available to an attacker (eg all public interfaces). If the classes thus revealed were hidden in a package by means of a private namespace but otherwise has public fields, the instances of these classes can now be attacked.

(3) The members method on UnionType reveals private constituents of a public/exported union type.

(4) Hidden base classes and base interfaces of public classes can be found by walking the superclass chain of a NominalType?.

(Please add more as you find them.)

[lth]

The likely fix for this is to add support for explicit namespace sets, as defined here: http://wiki.ecmascript.org/doku.php?id=proposals:name_objects.

[lth]

Also see #90.

[graydon]

These are all valid concerns and I agree with the direction of the proposed solution.

I wonder also if we ought to decide and/or state clearly in the text of the spec exactly how much we expect namespaces to serve as a security system. Users -- particularly casual programmers -- often think words like 'private' are far stronger than they are. I've heard people say they believed 'private' would somehow invoke the memory management hardware to protect their variables.

Another alternative to your proposed solution, if it proves too difficult, is to adopt the common lisp stance towards name control: namespaces (like packages) serve to organize, but not to enforce, the name structure of your program. I am partial to this solution, as I suspect the list of observability corner cases is actually quite long, and we'll keep stumbling into them long after we ship. But maybe that suspicion is just paranoia.

[brendan]

Graydon: I think we are already in the Lisp stance: if private can leak but you, the programmer writing the abstraction that uses private, have to work at it a bit, then it's not a security device and we shouldn't advertise it as such a thing. N00b wannabe-purists will scream, but they are misled or deluded.

It's true that with a VM-hosted portable language, we could work harder to protect private and user-defined equivalent namespaces from leaking. But we don't want to specify such a VM or require it for a conforming implementation. If security is really at stake, then such a fancy VM would seem to involve information flow and the notion of trust labels, which are not namespaces and nowhere else in ES4.

Either we break reflection including via for-in, or else allow it but provide integrity outside the class or package, so an attacker can't force a leak. The class or package implementor has to cooperate to leak a Namespace object reference. Is this different in any substantial way from the Lisp stance you mention?

/be

[graydon]

I believe in CL the package author does not have to collaborate to leak their names. They're really just advisory.

Anyways, all I meant was that we ought to be clear about the intent in the spec. Even if we try to patch up as many holes as possible via namespace sets and whatnot. Information leaks are hard.

[lth]

Build it and they will come.