Maximally minimal stack trace standardization

Mark S. Miller erights at google.com
Tue Mar 10 23:40:04 UTC 2015


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 <concavelenz at gmail.com> 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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150310/9777a8d8/attachment-0001.html>


More information about the es-discuss mailing list