Loading...

google-caja-discuss@googlegroups.com

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [Caja] Understanding Caja Mark S. Miller Mon Feb 13 00:00:15 2012

On Sun, Feb 12, 2012 at 10:32 PM, ๏̯͡๏ Jasvir Nagra <[EMAIL PROTECTED]>
 wrote:
[...]

> It is a goal for Caja on modern ES5-strict compliant browsers (what we
> call SES in our wiki) does seek to make cajoled code defensive against
> malicious uncajoled code.  However, we've not made a rigorous attempt to
> convince ourselves that the implementation currently achieves this goal.
>

Although such defensibility in SES is vastly stronger than with the Caja
translator, there are several ways in which SES cannot defend against an
uncajoled attacker. The most severe occurs on those browsers without a
built-in WeakMap, where we have to rely on our emulation. An uncajoled
attacker can see past the illusion that makes our WeakMap emulation work
and violate its integrity.

On browsers with built-in WeakMaps (currently only Firefox), the remaining
threats posed by uncajoled code are less severe. For example, an uncajoled
attacker can mutate a cajoled frame's Date.prototype in ways that confined
cajoled code in that frame can sense, opening up an overt global
communications channel.

We need to enumerate what these remaining weaknesses are. Until we do, this
scenario remains outside our threat model.