769265 - (CVE-2012-3979) Audit for incorrect uses of __android_log_print

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Blake Kaplan (:mrbkap) (inactive)]

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.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Fix

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b3ee916d45c3

Comment 3

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/b3ee916d45c3

Comment 4

[Daniel Veditz [:dveditz]]

We should fix this in Firefox 15.

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Please nominate for aurora uplift so we can look at getting this in before merge day on Monday July 16th.

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

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 7

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 637506 [details] [diff] [review]
Fix

This is already fixed in Aurora (16) so only approving for Beta (15)

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

https://hg.mozilla.org/releases/mozilla-beta/rev/a3391345c86a

Comment 9

[Daniel Veditz [:dveditz]]

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.

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

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.

Comment 11

[Christian Holler (:decoder)]

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.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

I confirmed that it's exposed to content (using http://gavinsharp.com/tmp/worker.html) and filed bug 785656.