Closed Bug 980051 Opened 11 years ago Closed 5 years ago

Information leakage vulnerability

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: curtisk, Unassigned)

Details

(4 keywords, Whiteboard: [reporter-external])

Attachments

(2 files)

TapSnooping-PoC
943 bytes, text/html
Details
TouchedGecko.png
28.01 KB, image/png
Details
Date: Mon, 3 Mar 2014 10:20:55 +0200 Message-ID: <CAHdFCDhN=c7fBYVc-=ti8oMeSo7WbhckN7=fZa-=DbeCczbd7g@mail.gmail.com> Subject: Mozilla Firefox Information Leakage Vulnerability From: Keith Makan <k3170makan@gmail.com> -----//----- #Discovery Date: 03/03/2014 #Affected Version: 27.0, possibly everything before this version. #Tested on: Samsung Galaxy S2, may affect all platforms* #Author: Keith Makan Description: Mozilla Firefox for Android handles console.log() messages by logging them to the Android logcat file. This allows attackers to potentially leak information about a victims browsing session---in addition to any information the browser has authority of, for instance autocomplete saved information, links the victim has visited etc.---to the logcat file by using the console.log() message JavaScript function. To exploit this an adversary needs have local context with an application that has READ_LOGS permission and have a victim browse to a crafted website. This also affects the private browsing mode in 27.0 *The vulnerability here in strict terms is that it allows data about the browsing session to be shared to a lower/alternative privilege level, namely from the browsers private application storage to the logcat file. If you want to protect and securely expose a user's information, the log file is not the way to go 0_o* PoC: <html> <body> <script> console.log("WoopWoop!!"); /*unique tag to grep for in the log*/ </script> </body> </html> Result: $adb logcat | grep WoopWoop E/GeckoConsole(10911): WoopWoop!! ////////////////\\\\\\\\\\\\\\\ From: Mozilla Security <security@mozilla.org> Date: Mon, 3 Mar 2014 17:25:01 -0500 To: Keith Makan <k3170makan@gmail.com> -----//----- Hi Keith, Thanks for contacting us to ensure we understand there are a couple of questions. We think what is being reported is that Firefox is mirroring console.log to the Android log system? Is this correct? There was a known issue on Android prior to 4.1 (JellyBean) where any app requesting READ_LOGS permission could read the log files and we had some bugs related to that. However, 3rd party apps (like Firefox) on non-rooted phones after 4.1 can not longer receive this permission. Knowing that, what version of Android is your test platform running and is the system rooted? Could you also give a more concrete example of information that would be a threat as what should be going into that log file, even if mirrored, should not be data that would be personal or pose a security threat. Thanks, -- Curtis Koenig Mozilla Corp. Security Program Manager ////////////////\\\\\\\\\\\\\\\ Date: Tue, 4 Mar 2014 00:58:13 +0200 Subject: Re: Mozilla Firefox Information Leakage Vulnerability From: Keith Makan <k3170makan@gmail.com> To: Mozilla Security <security@mozilla.org> -----//----- Hi Curtis :) Question 1: "We think what is being reported is that Firefox is mirroring console.log to the Android log system? Is this correct?" Yes your assumption is correct. My assumption is that you guys probably override the onConsoleMessage method in the andorid.webkit.WebChromeClient with a call to Log.i or something equivalent. Question 2: "...what version of Android is your test platform running and is the system rooted?" Yes my phone is rooted and running 4.3. BUT I was not reading the logs through another--if you will thirdparty--application, I was using the adb command line client to simulate the affect of a thirdparty app with READ_LOGS permission. I reported this vulnerability with the assumption that the READ_LOGS permissions was correctly enforced. Question 3: "Could you also give a more concrete example of information that would be a threat" So there a couple of points to consider here: > Client Side ONLY Tap Snooping attacks: I managed to demonstrate that its possible to leak the coordinates of screen touches on the page using the console.log function in JavaScript by loading up an HTML file on my SDCARD. What this means is that effectively the browser becomes a platform for key logging---or tap/touch logging as it were on touch screen phones. Of course this then allows attackers to snoof login forms to popular sites and proliferate authentication credentials by reading the Android log file with a malicious application. [see the attached HTML file for a PoC] > Effectively bypassing the Same origin policy for XSS attacks: Usually when you inject JavaScript into a users session using an XSS attack you at some point you may want to funnel off data to an external domain (passwords, keystrokes etc) and this means dealing with the same origin policy, which is pretty hard to beat, BUT because of this vulnerability attackers can mitigate the need to send data to another domain and instead use the console.log function to store it in the android log file, where all an applications with READ_LOGS permission can access it. Please see the attached documents for a PoC of the Client Side ONLY tap snooping attack. Kind Regards ;) On Tue, Mar 4, 2014 at 12:25 AM, Mozilla Security <security@mozilla.org> wrote: Hi Keith, Thanks for contacting us to ensure we understand there are a couple of questions. We think what is being reported is that Firefox is mirroring console.log to the Android log system? Is this correct? There was a known issue on Android prior to 4.1 (JellyBean) where any app requesting READ_LOGS permission could read the log files and we had some bugs related to that. However, 3rd party apps (like Firefox) on non-rooted phones after 4.1 can not longer receive this permission. Knowing that, what version of Android is your test platform running and is the system rooted? Could you also give a more concrete example of information that would be a threat as what should be going into that log file, even if mirrored, should not be data that would be personal or pose a security threat. Thanks, -- Curtis Koenig Mozilla Corp. Security Program Manager On 3 Mar, 2014, at 03:20 AM, Keith Makan <k3170makan@gmail.com> wrote: > #Discovery Date: 03/03/2014 > #Affected Version: 27.0, possibly everything before this version. > #Tested on: Samsung Galaxy S2, may affect all platforms* > #Author: Keith Makan > > Description: > Mozilla Firefox for Android handles console.log() messages by logging them to the Android logcat file. This allows attackers to potentially leak information about a victims browsing session---in addition to any information the browser has authority of, for instance autocomplete saved information, links the victim has visited etc.---to the logcat file by using the console.log() message JavaScript function. To exploit this an adversary needs have local context with an application that has READ_LOGS permission and have a victim browse to a crafted website. > > This also affects the private browsing mode in 27.0 > > *The vulnerability here in strict terms is that it allows data about the browsing session to be shared to a lower/alternative privilege level, namely from the browsers private application storage to the logcat file. If you want to protect and securely expose a user's information, the log file is not the way to go 0_o* > > PoC: > <html> > <body> > <script> > console.log("WoopWoop!!"); /*unique tag to grep for in the log*/ > </script> > </body> > </html> > > Result: > $adb logcat | grep WoopWoop > > E/GeckoConsole(10911): WoopWoop!! > -- > <Keith k3170makan Makan/> > > -- <Keith k3170makan Makan/> <TapSnooping-PoC> <TouchedGecko.png>
Flags: sec-bounty?
Subject: Re: Mozilla Firefox Information Leakage Vulnerability From: Keith Makan <k3170makan@gmail.com> To: Mozilla Security <security@mozilla.org> -----//----- Hi Curtis, I just realized what you meant by "not available for Third Party Apps" and I actually didn't know about the change in the READ_LOGS permission enforcement. The android team changed the protectionlevel of the READ_LOGS permission to "signature|system|development". This means your app needs to be signed under the same key as an application that already has the permission, or is a system application, or be dynamically granted this stranger "developer" permission which requires high access rights. So I now I don't think this is as easily exploitable as I originally did--unless someone is running an un-patched version or version before the permissions change, sorry about this. I'll keep digging ;) Kind Regards. On Wed, Mar 5, 2014 at 11:23 PM, Keith Makan <k3170makan@gmail.com> wrote: I'm pretty sure they will be able to figure it out, but I'll be around to respond ;) All I need to tell them is that they've overrode the onConsoleMessage method for the main WebChromeClient with a Log.i call containing the ConsoleMessage object parameter. But we'll see ;) Kind Regards
Given the limited real estate on the phone, was putting console.log/etc message into the Android log a conscious decision? Now that we have great remote debugging tools can we revisit that decision?
Flags: needinfo?(mark.finkle)
Keywords: sec-vector
I'll bring it up at the next meeting. We still get a lot of data from the logcat, which don't require anyone to start up devtools.
Flags: needinfo?(mark.finkle)
mark, any update on this?
Flags: needinfo?(mark.finkle)
Thinking about this. If a website can do console.log() of information to logcat, don't we have bigger concerns? Why worry about sending the information to logcat? The website could send the information to a server. Also, I forgot to mention this to the team. Adding to the next meeting agenda.
Flags: needinfo?(mark.finkle)
As Curtis mentioned, Android prevented third party apps from using the READ_LOGS permission with Android 4.1 (Jelly Bean). However, since Fennec is supported on devices as old as Android 2.3 (Froyo), we still need a fix that works for all Android versions in that range. At our meeting last week, we agreed that we should remove page logging from logcat. We may decide to add a developer pref (with a warning) for users that want to enable it.
I'd like to point out that even pre-4.1 apps have to explicitly request permission to read logs.
The lower severity on this bug does not meet the high/critical criteria for the bug bounty.
Flags: sec-bounty? → sec-bounty-
Keywords: csectype-disclosure, sec-low
Assignee: nobody → bnicholson
Assignee: bnicholson → nobody
Group: core-security → firefox-core-security
Group: firefox-core-security → mobile-core-security

Fixed by the OS blocking logcat from accessing data outside the app's knowledge. We no longer support any insecure versions of Android that allowed apps unrestricted access to logcat.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Product: Firefox for Android → Firefox for Android Graveyard
Group: mobile-core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: