Debugging something today, I realized that we have a few places where we incorrectly call __android_log_print in potentially exploitable ways. The fix is easy and coming up.
Created attachment 637506 [details] [diff] [review] Fix
We should fix this in Firefox 15.
Please nominate for aurora uplift so we can look at getting this in before merge day on Monday July 16th.
Comment on attachment 637506 [details] [diff] [review] Fix [Approval Request Comment] User impact if declined: Possible problems if people use dump in evil ways on Android. Testing completed (on m-c, etc.): The patch has been in m-c for a while. Risk to taking this patch (and alternatives if risky): Very low risk.
Comment on attachment 637506 [details] [diff] [review] Fix This is already fixed in Aurora (16) so only approving for Beta (15)
Will this do anything bad if people aren't actively debugging android? I'm guessing that __android_log_print bails out if not actually being used before doing the dangerous printf family stuff, and if so that reduces the severity here to sec-moderate since you could only target a handful of people debugging while visiting attack sites.
As far as I know, __android_log_print always prints stuff to the logcat. However, I don't know if there's anything that controls whether or not that's on. dougt might know more.
The advisory here says that this can only be exploited through dump() which is disabled by default. If this is the case, then this isn't sec-high. Of course if there's another way to supply the string from content, then that rating is perfectly valid.
As far as I know none of the dump() implementations touched in attachment 637506 [details] [diff] [review] are exposed to content, except maybe the Worker* ones. WorkerPrivate.cpp's implementation only uses it as a fallback if reporting to the console service fails, which shouldn't really ever happen in practice. WorkerScope.cpp's implementation looks to not be pref-controlled, which means that workers calling dump() can spam stdout in release builds, which seems like a bug we should fix regardless of the security implementations.
I confirmed that it's exposed to content (using http://gavinsharp.com/tmp/worker.html) and filed bug 785656.