Yes there is. When I have time again, I'll file bugs on them. I should have done this long ago. Thanks.
On Tue, Mar 10, 2015 at 4:34 PM, John Lenz <[email protected]> wrote: > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
