Maximally minimal stack trace standardization

John Lenz concavelenz at gmail.com
Wed Mar 11 19:00:19 UTC 2015


On Tue, Mar 10, 2015 at 9:10 PM, Mark S. Miller <erights at google.com> wrote:

> On Tue, Mar 10, 2015 at 9:02 PM, Domenic Denicola <d at domenic.me> wrote:
>
>>  I don’t see how any of this follows. SES can censor/remove/etc. either
>> the .stack getter or the .getStack function. They are isomorphic.
>>
>
> I can selectively provide or deny a given getStack function to different
> code in the same realm.
>

Can't you do the same by hiding "Error" in the same way that "window" is
hidden?  Through a proxy or subclass?


>
>
>>
>>
>> .stack already has very close to de-facto standard behavior.
>>
>
> Have you looked at the case analysis I go through in debug.js to parse the
> variety of stack formats we currently have?
>
>
>
>> We should be attempting to converge it to a standard, and not leaving it
>> a non-interoperable mess while adding a second API.
>>
>>
>>
>> I also don’t see why .stack cannot map backward through different source
>> maps. Again, a getter and a function are isomorphic in this regard.
>>
>
> In a given realm, there can only be one Error.prototype.stack. But what
> getStack function is in scope can differ per scope as well as per loader.
>
>
>
>>
>>
>> *From:* Mark S. Miller [mailto:erights at google.com]
>> *Sent:* Wednesday, March 11, 2015 12:12
>> *To:* Domenic Denicola
>> *Cc:* John Lenz; es-discuss; Erik Arvidsson
>>
>> *Subject:* Re: Maximally minimal stack trace standardization
>>
>>
>>
>> No, that makes the std SES API non-conformant to the std API, making
>> porting more difficult, and making it harder to write code that works in
>> both environments.
>>
>>
>>
>> Also, if you make it look like err.stack, then no matter what you stdize,
>> it will conflict with existing err.stack behavior, since they conflict with
>> each other. This makes the transition more difficult. If the new std
>> behavior looks like getStack(err), then it can be rolled out without
>> creating a transition conflict.
>>
>>
>>
>> As so often happens, the better security is the better modularity. If you
>> make it err.stack, then you have to make visible one canonical mapping to
>> source positions. If you make it getStack(err), then different getStack
>> functions might map backwards through different sourcemaps.
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 10, 2015 at 7:45 PM, Domenic Denicola <d at domenic.me> wrote:
>>
>>  Can’t we just have Error.prototype.stack be a getter that SES is
>> allowed to delete and hide away for its own purposes later?
>>
>>
>>
>> *From:* es-discuss [mailto:es-discuss-bounces at mozilla.org] *On Behalf Of
>> *John Lenz
>> *Sent:* Wednesday, March 11, 2015 08:35
>> *To:* Mark S. Miller
>> *Cc:* es-discuss; Erik Arvidsson
>> *Subject:* Re: Maximally minimal stack trace standardization
>>
>>
>>
>>  Ok, as long as we are clear there is an existing information leak on
>> non-v8 engines.
>>
>>
>>
>>
>>
>> On Tue, Mar 10, 2015 at 1:48 PM, Mark S. Miller <erights at google.com>
>> wrote:
>>
>>  On Chrome and Opera (v8), <
>> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js>
>> hides the stack. It is important that we not lose this.
>>
>>
>>
>> Regarding the rest, as previously discussed, there are enough differences
>> between browsers that there is no legacy we must codify because of web-wide
>> agreement. Take a look at the extensive efforts <
>> https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js>
>> makes to parse despite these differences in stack format. As long as we're
>> standardizing something not compat with web-wide legacy, as we must, we
>> might as well also fix this security leak in the process.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 10, 2015 at 1:24 PM, John Lenz <concavelenz at gmail.com> wrote:
>>
>>
>>
>>
>>
>> On Mon, Mar 9, 2015 at 5:45 PM, Mark S. Miller <erights at google.com>
>> wrote:
>>
>>   On Mon, Mar 9, 2015 at 5:02 PM, John Lenz <concavelenz at gmail.com>
>> wrote:
>>
>>
>>
>>
>>
>> On Mon, Mar 9, 2015 at 12:15 PM, Mark S. Miller <erights at google.com>
>> wrote:
>>
>>   On Sat, Mar 7, 2015 at 2:55 PM, John Lenz <concavelenz at gmail.com>
>> wrote:
>>
>>  I wanted to ping this thread and see how we could get "max-min stack
>> traces" to the next step?
>>
>>
>>
>> Hi John, the best way to take this to the next step is to read <
>> https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU/edit>
>> and submit a proposal to <https://github.com/tc39/ecma262>.
>>
>>
>>
>> "If you are a TC39 member representative, just submit a pull request for
>> your proposal."
>>
>>
>>
>> Since you are at a member organization, attend and participate actively
>> at TC39 meetings to advance your proposal through the process.
>>
>>
>>
>> Please keep in mind that the stack trace information should not be
>> available simply from the error object by itself, as that is a bad
>> information leak.
>>
>>
>>
>> The threads I dug up, simply state what you state here.  That there is an
>> "information leak".  Are filename and function names considered sensitive?
>> In what way?
>>
>>
>>
>> They reveal details of the callee's computation to the caller that the
>> callee should have been able to assume were private. See starting at middle
>> of 2nd paragraph of <
>> http://combex.com/papers/darpa-review/security-review.html#UniversalScope
>> >.
>>
>>
>>
>>
>>
>> the depth of the execution stack is visible, which could pose a risk in
>> certain scenarios: for instance, consider trusted code containing a
>> recursive function whose level of recursion depends on some sensitive data
>> (e.g., a secret cryptographic key), and suppose the recursive function is
>> called with arguments that induce it to hit an error condition and throw an
>> exception from deep within the recursion.  In such a case, the caller might
>> be able to learn something about the callee’s secrets by catching the
>> exception, examining the resulting stack trace, and recovering the stack
>> depth.  These scenarios do not occur in the DarpaBrowser, but have been
>> used in exploits on other systems.  Accordingly, though the risk for
>> DarpaBrowser is small, it should probably be repaired (Fixing this was
>> determined not to be hard).
>>
>>
>>
>>
>>
>>     --David Wagner and E. Dean Tribble,
>>
>>         "A Security Review of the Combex DarpaBrowser Architecture"
>>
>>
>>
>>
>>
>> Likewise, the risk here -- of only a stack of function names and source
>> positions -- is small. But it violates the normal privacy assumptions
>> between caller and callee; and fixing it is again not hard -- via getStack.
>>
>>
>>
>>
>>
>>
>>
>>   I did not intend to promote a "rich stack inspection API" such as V8
>> has.
>>
>>
>>
>> That's good, but there is one thing I really like about the rich
>> inspection API that it would be a shame to lose: The user doesn't have to
>> do their own adhoc parsing of yet another ad hoc textual format. Since this
>> format contains function names, we would then even need to worry about
>> maliciously chosen function names, intended to get this stack format
>> parsing code to misparse. If the stack is a stack of, for example, JSON
>> strings, then we avoid this hazard.
>>
>>
>>
>>
>>
>> Sure, but I feel like that is independent, I mostly want to codify what
>> already exists and standardize throw/rethrow behavior.   That is why I ask
>> about the information leak.  Error objects already have "stack" properties
>> on all the major browsers. If "stack" leaks information then they already
>> do and the rectification should be there. (It makes no sense to add a
>> "leak-free" API when a "leaky" one already exists).
>>
>>
>>
>>
>>
>> --
>>
>>     Cheers,
>>     --MarkM
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>     Cheers,
>>     --MarkM
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>     Cheers,
>>     --MarkM
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150311/9493f3b5/attachment-0001.html>


More information about the es-discuss mailing list