762216 - Crash Stats should not leak security issues

Status: RESOLVED WONTFIX

(Socorro :: Webapp, task)

Description

[Bob Clary [:bc] (inactive)]

https://crash-stats.mozilla.com/report/index/9935bec2-0d73-4459-a943-1bcce2120602

bug 762197

Note

Crash Reason	EXCEPTION_ACCESS_VIOLATION_EXEC
Crash Address	0xffffffffdadadada

0xdada is deleted memory. EXEC is, well, EXECUTION!

In crash automation, I use breakpad's exploitable tool on Windows as well as look for bad patterns in the crash address and registers. Can we do something similar for the web tool and hide potentially exploitable crashes except from logged in users?

Comment 1

[Bob Clary [:bc] (inactive)]

A special report available only to logged in users which shows the potentially exploitable crashes would be nice too. Also, Laura: may I have a pony? ;-)

Comment 2

[Benjamin Smedberg]

I really don't think we should do this without some more widespread discussion: a lot of the value in crash-stats is from the community, and I'd say that *most* of the crashes in crash-stats are probably exploitable one way or another. The _EXEC forms are probably a bit more obvious.

Comment 3

[Robert Kaiser]

Can we bring this up next week in stability work week discussions? I agree with Benjamin there, though. We know we are walking the line in terms of security and privacy vs. community involvement with crash-stats to a certain degree, if we start redacting stuff there, I'm pretty sure this can get hairy fast. Also, we are trying to bring in more community and not closing out community we have (our by far most helpful community member in crash analysis is even using a pseudonym, and I don't think we can afford to close him out from a lot of data, for example).

Comment 4

[Bob Clary [:bc] (inactive)]

Are only employees with ldap credentials allowed to log in now? What are the possibilities to opening this up to non employees? The thread on employees and the community in mozilla-governance hints that we might be adding some means of authenticating and vouching for community members.

For a bit of a scare, 

<https://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A13.0&range_value=1&range_unit=weeks&date=06%2F07%2F2012+22%3A21%3A37&query_search=signature&query_type=contains&query=&reason=EXCEPTION_ACCESS_VIOLATION_EXEC&build_id=&process_type=any&hang_type=any&do_query=1>

1,097 results for Firefox 13 in the last week.

Comment 5

[Robert Kaiser]

(In reply to Bob Clary [:bc:] from comment #4)
> Are only employees with ldap credentials allowed to log in now? What are the
> possibilities to opening this up to non employees?

"Log in" on Socorro means admin access to Socorro. That's only open to a small collection of highly trusted people. It need a Mozilla LDAP account, but not sure of what quality, I don't think it necessarily needs employee status, but we are extremely selective with who to give this to. Very probably not to anonymous people, though.
And I'm not even touching on how much we actually need to have public or not for someone new from the community to actually be able to join any kind of crash analysis work.

> For a bit of a scare,

Most of those are actually not scary or not scary to us in terms of what's public there. Things like EnterMethodJIT or the various Flash or third-party library crashes in there don't have any or much useful data at all which someone could use to exploit us, if that's possible at all (and e.g. JITed code is of course memory that we write to and then should make executable). Many of those we don't even have enough info at all for us to investigate what's going on, and most of those only when someone logged in actually downloads a minidump and analyzes it.
I'm not negating that there could be something exploitable in this query (I'm no developer and for sure no security engineer), but I know that a number of the things in there are actually harmless in terms of the data available publicly.

I think it's pretty hard to define what is safe to expose and what not. I wonder who might be around next week to actually have a session talking this through.

Comment 6

[Daniel Veditz [:dveditz]]

> (and e.g. JITed code is of course memory that we write to and then should make executable)

Yes, but it's memory we allocated and own. If we're getting access violations from JITed code things have gone very wrong in an almost certainly exploitable way.

Comment 7

[Bob Clary [:bc] (inactive)]

Even if we can't hide the potentially exploitable crashes from all users I think we should still:

1. run breakpad's exploitable tool on the windows crashes and assign an exploitability rating of low, medium, high.

2. investigate the crash address, registers and crash reason for patterns related to deleted or otherwise bogus memory and assign an exploitability rating. I have a crude heuristic I use in crash automation but would be interested in hearing what others think would work.

3. create a report available only to logged in users that lists the crash reports with a low, medium or high exploitability rating.

Comment 8

[Benjamin Smedberg]

Yes, I agree with comment 7.

Comment 9

[Benjamin Smedberg]

As filed, this is WONTFIX, but we are now running exploitable (it's in the DB) and will be exposing it in the UI soon.