> https://esdiscuss.org/topic/using-max-stack-limit-to-determine-current-js-engine-and-revision#content-7
> indicates there may be security issues with throwing out-of-memory exceptions.
That's hardly worth considering. The technique described there for
fingerprinting is interesting from a theorist's perspective, but exposing no
data that cannot already be more reliably extracted from navigator.userAgent
with a simple regex.
An out-of-memory in a sandbox is just exposing information about the sandbox,
and worth nothing therefore if the sandbox version itself isn’t already
compromised, at which point the user is generally screwed anyway if he didn't
patch in time. Being able to detect a vulnerability is not a prerequisite for
exploiting it.
Niels
-Original Message-
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Anne van
Kesteren
Sent: zaterdag 26 september 2015 16:35
To: Justin Novosad
Cc: WHAT Working Group ; Mark Miller
Subject: Re: [whatwg] Handling out of memory issues with
getImageData/createImageData
On Fri, Sep 25, 2015 at 4:48 PM, Justin Novosad wrote:
> Currently there is no spec'ed behavior for handling out-of memory issues
> for the specific case of attempting to allocate a large buffer through
> image data APIs.
Actually, there is no specified behavior for out-of-memory behavior,
period. This is a problem that starts with the ECMAScript standard and
everything that builds upon it.
I have seen Mark Miller discuss some of the issues surrounding this
and perhaps even the necessity to eventually define it, but so far
this has not happened. Not sure if the full story is documented
somewhere. Mark?
https://esdiscuss.org/topic/using-max-stack-limit-to-determine-current-js-engine-and-revision#content-7
indicates there may be security issues with throwing out-of-memory
exceptions.
--
https://annevankesteren.nl/