Module statics are like unhardened primordials

commons.js mostly exports primordials that will get hardened at lockdown. However, it also defines and exports some of its own functions such as

https://github.com/endojs/endo/blob/ef031843b445a4a9df7b717fba7a315371eadae0/packages/ses/src/commons.js#L91-L96

https://github.com/endojs/endo/blob/ef031843b445a4a9df7b717fba7a315371eadae0/packages/ses/src/commons.js#L154-L156

https://github.com/endojs/endo/blob/ef031843b445a4a9df7b717fba7a315371eadae0/packages/ses/src/commons.js#L243

which are potentially as global as shared primordials, and which it does not itself harden, or effectively harden by manual freezing. In theory this is not a security problem because these are not actually shared primordials, and should not be implicitly accessible from non-start compartments. This may be correct, but is an unnecessary hazard. Since commons.js must initialize before lockdown, it cannot actually use harden to fix this hazard. However, it should manually freeze enough to get the same effect. In particular, uncurryThis should freeze the function it returns.

I noticed this during https://github.com/endojs/endo/pull/888 which does not itself do anything to fix this hazard, but does propagate this hazard to one additional function.

[erights]

See https://github.com/endojs/endo/pull/892

Doesn’t stop

Crazy idea, could lockdown harden all object properties of the module namespace object of commons.js?

because we could still harden the values of those properties, addressing the immediate point.

[erights]

What is the status of this?