Comment #2 on issue 1444 by kpreid.switchb.org: Making WeakMap security not
depending on HIDDEN_NAME being neither unguessable nor undiscoverable
http://code.google.com/p/google-caja/issues/detail?id=1444
I've taken a look at this patch, and overall I think it is a great idea.
However, as already noted, it has a flaw:
+ * A case that has not been taken into account (yet) is when an
+ * attacker creates such a property in a non-visited object yet.
In particular, consider this attacker, which uses only operations that
cannot be monkeypatched:
var o = {};
o[HIDDEN_NAME] = {
set: function evil(k, v) { ... }
};
// now pass o to something which uses it in a WeakMap
The attacker now has:
1. stolen the WeakMap's internal leaky map (as k) (which is fixable
easily enough, by using a different token)
2. stolen the value intended to be set in the map (as v), and
3. is able to cause the WeakMap to misbehave.
The first fix that comes to mind is to have some form of trademarking of
the value of HIDDEN_NAME (that it is an authentic LeakyWeakMap). This would
not work in the cross-frame case (e.g. a frozen object could only be put in
WeakMaps belonging to the frame that froze it), but I think we can afford
that in current Caja (there is one SES frame and it touches objects from
its own frame and the host frame).
Any other ideas?
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
--
---
You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
