On Tue, Mar 10, 2015 at 9:10 PM, Mark S. Miller <[email protected]> wrote:
> On Tue, Mar 10, 2015 at 9:02 PM, Domenic Denicola <[email protected]> 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:[email protected]] >> *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 <[email protected]> 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:[email protected]] *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 <[email protected]> >> 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 <[email protected]> wrote: >> >> >> >> >> >> On Mon, Mar 9, 2015 at 5:45 PM, Mark S. Miller <[email protected]> >> wrote: >> >> On Mon, Mar 9, 2015 at 5:02 PM, John Lenz <[email protected]> >> wrote: >> >> >> >> >> >> On Mon, Mar 9, 2015 at 12:15 PM, Mark S. Miller <[email protected]> >> wrote: >> >> On Sat, Mar 7, 2015 at 2:55 PM, John Lenz <[email protected]> >> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
