Maximally minimal stack trace standardization

Mark S. Miller erights at google.com
Tue Mar 10 00:45:27 UTC 2015


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.


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150309/58c6d04c/attachment-0001.html>


More information about the es-discuss mailing list