{"id":"GHSA-whpx-q3rq-w8jc","aliases":[],"status":"published","title":"Hardening of TypedArrays with non-canonical numeric property names in SES","description":"### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nIn Hardened JavaScript, programs can `harden` objects to safely share objects with co-tenant programs without risk of these other programs tampering with their API surface. Hardening does not guarantee that objects are pure or immutable, so a hardened `Map`, for example is superficially tamper-proof, but any party holding a reference to the object can both read and write its contents. Based on this precedent, and because `TypedArray` instances cannot be frozen with `Object.isFrozen`, `harden` does not `freeze` `TypedArrays` and instead makes them non-extensible and makes all non-indexed properties non-writable and non-configurable. This is consistent with the treatment of `Map` because the indexed properties represent mutable content and non-indexed properties represent the API.\n\nDue to a defect in `harden`, properties that have names that parse as numbers but are not the same as the canonical representation of those numbers, as in `\"+0\"` and `\"\"` which are both equivalent to their canonical number `\"0\"`,  remain writable after hardening.\n\nAny program treating one of these properties as part of its API and relying on `harden` to prevent modifications would be vulnerable to an API pollution attack, affecting only instances shared by mutually suspicious parties.\n\nUnlike a `Map`, a hardened `TypedArray` can only have numbers for content. Any program that is sharing hardened `TypedArrays` between co-tentant programs and relying on harden to only allow these programs to communicate exclusively by changing numbers within the bounds of the TypedArray, may inadvertently have arranged for a mechanism for a pair of third-parties to communicate arbitrary objects on these other properties.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nSES version 0.16.0 patches this issue, causing `harden` to recognize properties with non-canonical numeric representations and ensuring that these properties are non-configurable.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nUsers should avoid sharing `TypedArrays` between co-tenant programs and instead create wrapper objects that produce a read-only view of the underlying data. We allow `harden` to succeed for `TypedArrays` because the treatment is in fact consistent with the behavior of collections like `Map`, but all collections shared between co-tentant programs should probably be attenuated to either read- or write-only facets and probably close over only part of the content of the collection. However, the motivation for allowing `TypedArrays` to be hardened in practice is to allow certain legacy modules to function under Hardened JavaScript with LavaMoat, since they export `TypedArrays`, even though they would ideally export read-only facets of these.\n\n### References\n_Are there any links users can visit to find out more?_\n\nNot at this time.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [security@agoric.com](mailto:security@agoric.com)","facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"published":"2022-10-20T18:38:35Z","modified":"2023-01-09T05:07:54Z","fixes":[{"ecosystem":"npm","package":"ses","fixed_in":["0.16.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"ses","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.16.0"}]}]},{"source":"osv","ecosystem":"npm","package":"ses","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.16.0"}]}]}],"references":[{"url":"https://github.com/endojs/endo/security/advisories/GHSA-whpx-q3rq-w8jc","tags":["web"]},{"url":"https://github.com/endojs/endo/commit/88cab0be4cf816dc578f2ff441fd9bcda0aa5cf5","tags":["web"]},{"url":"https://github.com/advisories/GHSA-whpx-q3rq-w8jc"},{"url":"https://github.com/endojs/endo","tags":["package"]}],"sources":{"ghsa":[{"id":"GHSA-whpx-q3rq-w8jc","title":"Hardening of TypedArrays with non-canonical numeric property names in SES","description":"### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nIn Hardened JavaScript, programs can `harden` objects to safely share objects with co-tenant programs without risk of these other programs tampering with their API surface. Hardening does not guarantee that objects are pure or immutable, so a hardened `Map`, for example is superficially tamper-proof, but any party holding a reference to the object can both read and write its contents. Based on this precedent, and because `TypedArray` instances cannot be frozen with `Object.isFrozen`, `harden` does not `freeze` `TypedArrays` and instead makes them non-extensible and makes all non-indexed properties non-writable and non-configurable. This is consistent with the treatment of `Map` because the indexed properties represent mutable content and non-indexed properties represent the API.\n\nDue to a defect in `harden`, properties that have names that parse as numbers but are not the same as the canonical representation of those numbers, as in `\"+0\"` and `\"\"` which are both equivalent to their canonical number `\"0\"`,  remain writable after hardening.\n\nAny program treating one of these properties as part of its API and relying on `harden` to prevent modifications would be vulnerable to an API pollution attack, affecting only instances shared by mutually suspicious parties.\n\nUnlike a `Map`, a hardened `TypedArray` can only have numbers for content. Any program that is sharing hardened `TypedArrays` between co-tentant programs and relying on harden to only allow these programs to communicate exclusively by changing numbers within the bounds of the TypedArray, may inadvertently have arranged for a mechanism for a pair of third-parties to communicate arbitrary objects on these other properties.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nSES version 0.16.0 patches this issue, causing `harden` to recognize properties with non-canonical numeric representations and ensuring that these properties are non-configurable.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nUsers should avoid sharing `TypedArrays` between co-tenant programs and instead create wrapper objects that produce a read-only view of the underlying data. We allow `harden` to succeed for `TypedArrays` because the treatment is in fact consistent with the behavior of collections like `Map`, but all collections shared between co-tentant programs should probably be attenuated to either read- or write-only facets and probably close over only part of the content of the collection. However, the motivation for allowing `TypedArrays` to be hardened in practice is to allow certain legacy modules to function under Hardened JavaScript with LavaMoat, since they export `TypedArrays`, even though they would ideally export read-only facets of these.\n\n### References\n_Are there any links users can visit to find out more?_\n\nNot at this time.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [security@agoric.com](mailto:security@agoric.com)\n","status":"published","published":"2022-10-20T18:38:35Z","modified":"2023-01-09T05:07:54Z","updated_at":"2026-11-02T14:36:12.361159Z"}],"osv":[{"id":"GHSA-whpx-q3rq-w8jc","title":"Hardening of TypedArrays with non-canonical numeric property names in SES","description":"### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nIn Hardened JavaScript, programs can `harden` objects to safely share objects with co-tenant programs without risk of these other programs tampering with their API surface. Hardening does not guarantee that objects are pure or immutable, so a hardened `Map`, for example is superficially tamper-proof, but any party holding a reference to the object can both read and write its contents. Based on this precedent, and because `TypedArray` instances cannot be frozen with `Object.isFrozen`, `harden` does not `freeze` `TypedArrays` and instead makes them non-extensible and makes all non-indexed properties non-writable and non-configurable. This is consistent with the treatment of `Map` because the indexed properties represent mutable content and non-indexed properties represent the API.\n\nDue to a defect in `harden`, properties that have names that parse as numbers but are not the same as the canonical representation of those numbers, as in `\"+0\"` and `\"\"` which are both equivalent to their canonical number `\"0\"`,  remain writable after hardening.\n\nAny program treating one of these properties as part of its API and relying on `harden` to prevent modifications would be vulnerable to an API pollution attack, affecting only instances shared by mutually suspicious parties.\n\nUnlike a `Map`, a hardened `TypedArray` can only have numbers for content. Any program that is sharing hardened `TypedArrays` between co-tentant programs and relying on harden to only allow these programs to communicate exclusively by changing numbers within the bounds of the TypedArray, may inadvertently have arranged for a mechanism for a pair of third-parties to communicate arbitrary objects on these other properties.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nSES version 0.16.0 patches this issue, causing `harden` to recognize properties with non-canonical numeric representations and ensuring that these properties are non-configurable.\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nUsers should avoid sharing `TypedArrays` between co-tenant programs and instead create wrapper objects that produce a read-only view of the underlying data. We allow `harden` to succeed for `TypedArrays` because the treatment is in fact consistent with the behavior of collections like `Map`, but all collections shared between co-tentant programs should probably be attenuated to either read- or write-only facets and probably close over only part of the content of the collection. However, the motivation for allowing `TypedArrays` to be hardened in practice is to allow certain legacy modules to function under Hardened JavaScript with LavaMoat, since they export `TypedArrays`, even though they would ideally export read-only facets of these.\n\n### References\n_Are there any links users can visit to find out more?_\n\nNot at this time.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [security@agoric.com](mailto:security@agoric.com)\n","status":"published","published":"2022-10-20T18:38:35Z","modified":"2022-10-20T18:38:35Z","updated_at":"2026-11-02T15:46:58.767335Z"}]}}