1

OVERTAKING FIREFOX PROFILESVulnerabilities in Firefox for Android

Roee HayIBM Security Systems

roeeh@il.ibm.com

Abstract—We present newly-found vulnerabili-ties in the Firefox Android Application. Exploitingthem allows a malicious application to successfullyderandomize the Firefox profile directory name ina practical amount of time and exfiltrate sensitivedata (such as cookies and cached information)which reside in that directory, breaking Android’ssandbox.

Index Terms—CVE-2014-1484; CVE-2014-1506; CVE-2014-1515; CVE-2014-1516.

I. Android basics

A. Threat model

Android applications are executed in a sandboxenvironment to ensure that no application can accesssensitive information held by another without properprivileges. For example, Android’s browser appli-cation holds sensitive information such as cookies,cache and history which cannot be accessed by third-party apps. An android application may request spe-cific privileges (permissions) during its installation;if granted by the user, the capabilities are extended.Permissions are defined under the application’s man-ifest file, namely AndroidManifest.xml.

B. Activities and Services

Android applications are composed of compo-nents of different types including activities andservices. An Activity, implemented by the an-

droid.content.Activity class [1], defines a singleUI, e.g. a browsing window or a preferences screen.Services [2] are application components that are usedfor background tasks.

C. Inter-Process Communication (IPC) and Intents

Android applications communicate with each otherthrough Intents. These are messaging objects thatcontain several attributes such as an action, data,category, target and extras. The data attribute isa URI which identifies the Intent (e.g. tel:0422123).Each Intent can also contain extra data fields, namely

Intent extras, which reside inside a Bundle (imple-mented by the android.os.Bundle class [3]). Intentextras can be set by using the Intent.putExtra

API or by manipulating the extras Bundle directly.It is important to emphasize that intents provide achannel for a malicious application to inject maliciousdata into a target, potentially vulnerable application.Intents can have either explicit or implicit destina-tion, depending whether targets are specified or not.Intents can be broadcast, passed to the startActiv-ity call (when an application starts another activ-ity), or passed to the startService call (when anapplication starts a service). Under the application’smanifest file, an application component may claimwhether it can be invoked externally using an Intent,and if so which set of permissions is required. Wedefine a public application component as one whichcan be invoked externally by a (potentially malicious)application without any permissions. All other com-ponents are defined as private, i.e. they can only beinvoked by other application components of the samepackage, or externally with proper privileges.

II. Generation of the Profile Directory

Firefox stores the personal data under the profiledirectory, located at files/mozilla/X.default/

where X is a randomly chosen 8-byte word overthe alphanumeric alphabet [a-z0-9]. The gener-ation of X.default is implemented at GeckoPro-

file.saltProfileName (Figure II.1).Since the profile directory name is random, Firefox

stores a mapping under the files/mozilla/pro-

files.ini file (Figure II.2)If Firefox does not find a valid profile, for example

due to a missing profiles.ini, it creates a new oneby invoking GeckoProfile.createProfileDir.

III. Vulnerabilities

A. Profile Directory Name Weak Randomization

The Math.random() static method returns a uni-formly distributed pseudo-random number between

2

1 private stat ic St r ing2 sa l tPro f i l eName ( St r ing name)3 {4 St r ing al lowedChars =5 ”abcdefghi jklmnopqrstuvwxyz0123456789 ” ;67 S t r i ngBu i l d e r s a l t =8 new St r ingBu i l d e r ( 1 6 ) ;9

10 for ( int i = 0 ; i < 8 ; i++) {11 s a l t . append ( al lowedChars . charAt ( ( int )12 (Math . random ( ) ∗13 al lowedChars . l ength ( ) ) ) ) ;14 }15 s a l t . append ( ’ . ’ ) ;16 s a l t . append (name ) ;17 return s a l t . t oS t r i ng ( ) ;18 }

Figure II.1. GeckoProfile.saltProfileName(String name)

[Profile0]

Default=1

Name=default

IsRelative=1

Path=475jbgu6.default

[General]

StartWithLastProfile=1

Figure II.2. profiles.ini

0 and 1. In Android, the implementation is underlibcore1:

1 public stat ic synchronized double random ( )2 {3 i f ( random == null )4 {5 random = new Random ( ) ;6 }7 return random . nextDouble ( ) ;8 }

Figure III.1. Math.random()

We can see that this method relies on thejava.util.Random class which is seeded in its de-fault constructor. In Android 4.4 and below, it isimplemented as follows2:

1https://android.googlesource.com/platform/libcore/2https://android.googlesource.com/platform/libcore/+/android-4.4 r1.2/luni/src/main/java/java/util/Random.java

1 public Random( )2 {3 se tSeed ( System . cur r entT imeMi l l i s ( )4 + System . identityHashCode ( this ) ) ;5 }

Figure III.2. java.util.Random’s constructor

Therefore the seed depends on a couple of values:

1) The current time in milliseconds precision(System.currentTimeMillis())

2) The identity hash code of the Random object(System.identityHashCode(this))

System.identityHashCode is implemented by na-tive code in the Dalvik VM implementation3. Theidentity hash code value is the object’s Virtual Ad-dress (VA) which resides in the heap of the DalvikVM process.GeckoProfile.saltProfileName uses

Math.random() which is cryptographically insecure.We have seen that its seed relies on the inner-Random object creation time (in ms precision) andits VA. Both factors are not random. The creationtime can be leaked by an adversary (see IV-A1b)and the VA lacks randomness due to ineffectiveASLR in the Dalvik VM process [4], [5]. Since theDalvik VM is forked from the Zygote process, theVA of the Dalvik Heap is the same for all AndroidDalvik applications. To conclude, the seed is notrandom, thus the profile directory name entropy isfar from the ideal 41.36 random bits (log2 368) andcan be predicted by the adversary as we will seenext.

B. Profile Directory Name Leaks to Android SystemLog

The random Profile Directory Name is written tothe Android System Log (logcat) in various locations.For instance, upon Firefox launch, the following datais written:

D/GeckoProfile( 4766): Found profile dir:/data/data/.../files/mozilla/24pd90uh.default

In Android 4.0 and below, the Android log can easilybe read by all applications including malicious onesby acquiring the READ_LOGS permission. Android 4.1has introduced a change to this behavior to preventsuch log leakage attacks: the READ_LOGS permissionis no longer required, however applications can onlylisten to their own log. In section IV-B we show howa malicious app can manipulate Firefox to leak itsown private log in order to overcome this obstacle.

3https://android.googlesource.com/platform/dalvik.git/+/android-4.4 r1.2/vm/Sync.cpp

3

C. Automatic File Download to SD Card

Any file which cannot be rendered by Fire-fox is automatically downloaded to the SD card(/mnt/sdcard/Download), a folder which can beread by a malicious application by acquiring theREAD_EXTERNAL_STORAGE permission. Interestingly,this permission was not even enforced before Android4.44. This allows a malicious application to extractnon-renderable data such as the cookies database,once it has managed to derandomize the profiledirectory name.

D. Crash Reporter File Manipulation

The org.mozilla.gecko.CrashReporter class isa public activity. Its purpose is to send crash dumpsto Mozilla when needed (Figure III.3). The CrashRe-porter activity receives the dump file path as aninput (an Intent extra parameter). When the activityis launched, its onCreate method (Figure III.4) isexecuted and the following actions take place:

1) Using the moveFile (Figure III.5) method, thegiven minidump file is moved to the pendingminidumps path, files/mozilla/Crash Re-

ports/pending.

2) A meta-data filename is deduced from the givenminidump file path, by replacing all ’.dmp’occurrences with ’.extra’. i.e. <filename>.dmpbecomes <filename>.extra.

3) The meta-data file is moved to the pendingminidumps path using the moveFile method.

4) The meta-data file is parsed as a key/value fileformat (Figure III.6). The target server URL(i.e. the one that the crash information is sentto) is specified here using the ServerURL key.

5) The crash dialog is presented to the user (Fig-ure III.3).

If the user presses the Close or Restart buttons withthe Send report check-box enabled, the minidumpalongside with other sensitive information is sentto the specified server by calling the sendReport

method. It should be noted that if the user hasalso checked the Include the address check-box, thenAndroid logs are sent as well.

The CrashReporter activity consumes theminidump path from the input intent (Figure III.4,Line 4) although it should be considered untrusteddata since the activity is public as defined inthe Android Manifest file. Therefore, a maliciousapplication can control the source path of themoved minidump file and the deduced extra file

4http://developer.android.com/reference/android/Manifest.permission.html#READ EXTERNAL STORAGE

Figure III.3. Crash Reporter dialog

(Figure III.4, Lines 8, 11). We will see in the nextsection that this allows that attacker to control thedestination server for the crash report, hence theresponse value used as a file path in Figure III.7,Line 19 should be untrusted as well.

IV. Exploitation

The attacker (by the use of a malicious appli-cation) can exploit a subset of the aforementionedvulnerabilities in order to:

1) Derandomize the profile directory path.2) Exfiltrate sensitive data (such as cookies and

cached information) from the profile directory.

In this section we describe several attractive exploita-tion suites.

A. Suite I: Exploiting Vulnerabilities III-A, III-C andoptionally III-D

1) Derandomizing the Profile Path: Let Y be theseed chosen by Firefox. The goal of the attacker is toderandomize it by recording some value which sharesa strong relation with it. Both the VA and the timeparts of the seed cannot be entirely determined bythe attacker, however, most of their bits can be leakedto the attacker using simple actions:

a) Derandomizing the VA Value: To obtainparts of the VA, as per the ineffective ASLR, theattacker can query its own process using the Sys-

tem.identitiyHashCode routine on some object.

4

b) Derandomizing the Time Value: The mstime value can be leaked in two different ways.First, if Firefox had been installed after the ma-licious app, the latter can record the first Firefoxrun by simply monitoring the device’s process list.Otherwise, the attacker app can exploit Vulnera-bility III-D to move the profiles.ini file (whichhas a deterministic path) to the different direc-tory. The exploitation is done by sending an Intentto the Crash Reporter with minidumpPath Intentextra set to /data/data/org.mozilla.firefox/-

files/mozilla/profiles.ini. Firefox will create anew profile on its next run, which can be forced bycrashing it (this can be done by exploiting Vulnera-bility III-D, sending an Intent to the Crash Reporterwithout a minidumpPath extra). Again the attackercan record the Firefox launch time.

Let X be the attacker’s inaccurate sample whereX = V A + MeasuredT ime. Let ε be the error,i.e. ε = Y − X. In our brute-force attack we tryvalues in the order of their inferred probabilitieswhich can be computed offline by the attacker (seeSection V). Let N be the number of attempts untila success, then the expected number of attempts isE(N) =

∑nk=1 k·p(k) where {p(k)}nk=1 are the ordered

inferred probabilities (p(1) ≥ p(2) ≥ · · · ≥ p(n)).Please note that the expression for E(N) provesthat this is the optimal search algorithm (in termsof the expectation). A simpler model is to assumethat ε is a (discrete) bell-curve with the centerestimated by ε = x-y. It can be shown that E(N) =O(E|X − EX|) = O (σε) so a more narrow bell-curve yields a shorter attack time (on average). Byusing the inferred probabilities of ε and the sampledseed, X, the attacker creates a list of profile namesby mimicking the GeckoProfile.saltProfileName

implementation (this computation can be also doneoff the device and downloaded from the attacker).

2) Data Exfiltration: This phase is online. Theattacker creates a specially crafted world-readableHTML file and commands Firefox to load it (by usingan Intent). This file includes the list of profile namesordered by their probabilities generated previously.The JavaScript code in the HTML file goes over thelist, searching for the correct profile. When there isa match, it can download any file under the profilesdirectory by creating an iframe targeting the file-name. As per Vulnerability III-C, if Firefox cannotrender the file, it will automatically download the fileto the SD card (/mnt/sdcard/Download), a folderwhich can be read by the attacker.

B. Suite II: Exploiting Vulnerabilities III-B, III-Cand optionally III-D

1) Derandomizing the Profile Path : On Android4.0 and below, the Android System Log can easily beread by the malicious app. This allows the maliciousapp to exploit Vulnerability III-B and deduce theprofile directory path.

Android 4.1 prevents this attack as applicationscan only listen to their own logs. Since Firefox sendsits own private log alongside the crash report (seeSection III-D) , Vulnerability III-D can be exploitedfor sending the logs to the attacker:

• The malicious app creates two worldreadable files under its data directory:/data/data/<malicious app>/foo.dmp withan arbitrary content (can be left empty) and/data/data/<malicious app>/foo.extra

which contains the attacker’s server,ServerURL=http://<attacker>/.

• The malicious app generates an Intent ob-ject which targets the CrashReporter activitywith a minidumpPath parameter set to /data/-

data/<malicious app>/foo.dmp

After the above actions take place, according to theoperation of the CrashReporter activity (see SectionIII-D), Firefox will move foo.dmp and foo.extra

from the malicious app data directory to the Fire-fox crash reports pending path and then parsefoo.extra for key-value pairs. Since the extra filenow contains the attacker’s IP as the ServerURL, ifthe user pressed one of the buttons on the CrashRe-

porter dialog, Firefox would send the crash reportto the attacker. If the user has also checked theInclude the address check-box, then Firefox wouldalso append the Android Log output, which containsthe Firefox private logs that include the randomprofile directory name. It should be noted that sinceFirefox only sends a 200 lines window of the log, theleaked path can be out of that window since it islogged upon Firefox’s launch. In order to make surethat the path is within the window, the attacker canrestart Firefox by crashing it. This can be easily doneby invoking the CrashReporter activity without aminidumpPath parameter.

2) Data Exfiltration: Once the attacker has learntthe profile path, he can leak files by exploiting Vul-nerability III-C. The attacker simply invokes Firefoxusing an Intent with a payload set to the target filepath.

C. Suite III: Exploiting Vulnerabilities III-B andIII-D

1) Derandomizing the Profile Path Seed: This partis exactly as described in Section IV-B1.

5

2) Data Exfiltration: Here we exploitVulnerability III-D. We indirectly inject theServerURL=http://<attacker> string to the targetfile and trick Firefox to use this file as the minidumpextra. For instance, by using this method, theattacker can leak the cache. First, he opens Firefox(using an Intent) on an attacker’s controlled website,which contains the above string in its HTML body(Figure IV.1). After the cache has been prepared,the attacker can leak it by generating another Intentthat targets the CrashReporter activity, with theminidump path parameter set to the cache file. Sincethe cache file path has no ’.dmp’ substring, thecomputed extra file will be the same, and the targetserver URL will be parsed out of the cache file.

1 <HTML>2 <BODY>3 ServerURL=http : //<ATTACKER>4 </BODY>5 </HTML>

Figure IV.1. Injected payload into Firefox’s cache

V. Evaluation

We tested our Suite I exploit on Firefox 25.0.1running on Samsung GT-I9500 Galaxy S4 deviceequipped with Android 4.2.2. In order to infer theprobabilities of ε we ran 404 independent runs of thefollowing test:

1) Call Math.Random() and retrieve its identi-

tyHashCode (Figure V.1)2) Start monitoring the process list in a frequency

of 20 Hz for recording the Firefox launch time.3) Remove the profiles.ini file from the Firefox

directory by exploiting Vulnerability III-D.4) Record the created profile directory.5) Kill Firefox.6) Restart Firefox.7) Print the needed values.

1 Math . random ( ) ;2 F i e ld f = Math . class .3 ge tDec la r edF i e ld ( ”random” ) ;4 f . s e tA c c e s s i b l e ( true ) ;5 Random r = (Random) f . get ( null ) ;6 Long addr = System . identityHashCode ( r ) ;

Figure V.1. Retrieving the identityHashCode of the Mathinner Random object

For example, for each run we received and recordedthe following data:

Sampled VA: 42dc6cd8

Sampled Time: 1385337348079

Sampled Seed: 142cf66ccc7

Created profile: xa1x453r.default

Later we calculated the real seed and ε by an offlinebrute-force. For example, for the data above, the realseed is 1386459232784 and ε = 142665.

We witnessed three strong linear correlations be-tween Y and X (Figure V.2). We believe that thereason for the less dense lines rely on Dalvik Heapinternals which caused the offset to ’jump’ with afixed number for a few tests (i.e. the probability forthis to happen is low).

�

�������

�������

�������

�������

��������

��������

��������

��������

� ������� ������� ������� ������� �������� �������� ��������

Figure V.2. Linear correlation between the real seed and thesampled one

We created a histogram for inferring the distribu-tion of ε (Figure V.3) and calculated the expectednumber of attempts, E(N), which is 152779.65 andis equivalent to 17.22 bits. Note that the Shannonentropy is very close, 18.63 bits. We’ve got an entropywhich is much lower than the ideal 64 bits (the javalong primitive size) seed entropy, thus the attack isfeasible.

�

����

����

����

����

���

����

����

������� ������ ����� ������ ������� ������� ������

Figure V.3. ε Histogram

We then adhered to the steps of section IV-A,taken the simpler approach where we assert a sym-metric bell curve. Since we received three linear

6

correlations, we have taken a slightly different ap-proach. We denote p1, p2, p3 as the probabilities forthe error to be taken from each curve and assert thateach error is normally distributed with its respectivevariance (the actual discrete error is the roundedvalue, see Figure V.4). Therefore ε1 ∼ N

(0, σ2

1

)with

probability p1 , ε2 ∼ N(0, σ2

2

)with probability p2

and ε3 ∼ N(0, σ2

3

)with probability p3. We brute-

force in the order of the probabilities. We ran ourexploit and successfully caused Firefox to downloadsensitive files into the SD card which can be read bythe attacker (Figure V.5). It should be noted thataccording to the ’normalized’ model, the expectednumber of tries is 214373.3 which is equivalent to17.709 bits.

�

����

����

����

����

���

����

������� ������ ����� ������ ������� ������� ������

Figure V.4. Normalized−ε histogram

VI. Identifiers & Fix VersionsVulnerability CVE ID Fix Version

III-A CVE-2014-1516 TBA5

III-B CVE-2014-1484 Firefox 27III-C CVE-2014-1515 Firefox 28.0.1III-D CVE-2014-1506 Firefox 28

VII. Disclosure Timeline03/25/2014 Public disclosure.03/25/2014 Firefox 28.0.1 is released, fixing

Vulnerability III-C03/18/2014 Firefox 28 is released, fixing

Vulnerability III-D03/15/2014 Permission granted.03/12/2014 Requested permission to disclose

Vulnerability III-A despite lack of fix.02/04/2014 Firefox 27 is released, fixing

Vulnerability III-B11/28/2013 Reported Vulnerabilities.

5As its severity is now much lower with the CVE-2014-1515fix, we were allowed by Mozilla to publicly disclose this unfixedvulnerability.

Figure V.5. Automatic File Download (exploiting Vulnerabil-ity III-C)

References

[1] Activity class reference. http://developer.android.com/reference/android/app/Activity.html.

[2] Service class reference. http://developer.android.com/reference/android/app/Service.html.

[3] Bundle class reference. http://developer.android.com/reference/android/os/Bundle.html.

[4] Byoungyoung Lee, Long Lu, Tielei Wang, Taesoo Kim, andWenke Lee. From Zygote to Morula: Fortifying WeakenedASLR on Android. In IEEE Symposium on Security andPrivacy, 2014.

[5] Jon Oberheide. A look at ASLR in An-droid Ice Cream Sandwich 4.0, February2012. https://www.duosecurity.com/blog/a-look-at-aslr-in-android-ice-cream-sandwich-4-0.

7

1 @Override2 public void onCreate ( Bundle savedIns tanceState ) {3 . . .4 S t r ing passedMinidumpPath = ge t In t en t ( ) . ge tSt r ingExtra (PASSED MINI DUMP KEY) ;5 F i l e passedMinidumpFile = new F i l e ( passedMinidumpPath ) ;6 F i l e pendingDir = new F i l e ( g e tF i l e sD i r ( ) , PENDING SUFFIX) ;7 pendingDir . mkdirs ( ) ;8 mPendingMinidumpFile = new F i l e ( pendingDir , passedMinidumpFile . getName ( ) ) ;9 moveFile ( passedMinidumpFile , mPendingMinidumpFile ) ;

10 F i l e e x t r a sF i l e = new F i l e ( passedMinidumpPath . r e p l a c eA l l ( ” .dmp” , ” . ext ra ” ) ) ;11 mPendingExtrasFile = new F i l e ( pendingDir , e x t r a sF i l e . getName ( ) ) ;12 moveFile ( e x t r a sF i l e , mPendingExtrasFile ) ;13 mExtrasStringMap = new HashMap<Str ing , Str ing >() ;14 readStr ingsFromFi le ( mPendingExtrasFile . getPath ( ) , mExtrasStringMap ) ;15 . . .16 }

Figure III.4. onCreate method under CrashReporter

1 private boolean moveFile ( F i l e i nF i l e , F i l e ou tF i l e ) {2 Log . i (LOGTAG, ”moving ” + i nF i l e + ” to ” + outF i l e ) ;3 i f ( i nF i l e . renameTo ( ou tF i l e ) )4 return true ;5 try {6 outF i l e . createNewFi le ( ) ;7 Log . i (LOGTAG, ”couldn ’ t rename minidump f i l e ” ) ;8 // so copy i t i n s t ead9 Fi leChannel inChannel = new Fi leInputStream ( i nF i l e ) . getChannel ( ) ;

10 Fi leChannel outChannel = new FileOutputStream ( outF i l e ) . getChannel ( ) ;11 long t r a n s f e r r e d = inChannel . t rans f e rTo (0 , inChannel . s i z e ( ) , outChannel ) ;12 inChannel . c l o s e ( ) ;13 outChannel . c l o s e ( ) ; p r i o r to14 i f ( t r a n s f e r r e d > 0)15 i nF i l e . d e l e t e ( ) ;16 } catch ( Exception e ) {17 Log . e (LOGTAG, ”except ion whi le copying minidump f i l e : ” , e ) ;18 return fa lse ;19 }20 return true ;21 }

Figure III.5. moveFile method under CrashReporter

8

1 private boolean readStr ingsFromFi le ( S t r ing f i l ePa th , Map<Str ing , Str ing> stringMap ) {2 try {3 BufferedReader reader = new BufferedReader (new Fi leReader ( f i l ePa t h ) ) ;4 return readStringsFromReader ( reader , stringMap ) ;5 } catch ( Exception e ) {6 Log . e (LOGTAG, ”except ion whi l e read ing s t r i n g s : ” , e ) ;7 return fa lse ;8 }9 }

1011 private boolean readStringsFromReader ( BufferedReader reader , Map<Str ing , Str ing> stringMap )12 throws IOException {13 St r ing l i n e ;14 while ( ( l i n e = reader . readLine ( ) ) != null ) {15 int equalsPos = −1;16 i f ( ( equalsPos = l i n e . indexOf ( ’=’ ) ) != −1) {17 St r ing key = l i n e . sub s t r i ng (0 , equalsPos ) ;18 St r ing va l = unescape ( l i n e . sub s t r i ng ( equalsPos + 1 ) ) ;19 stringMap . put ( key , va l ) ;20 }21 }22 reader . c l o s e ( ) ;23 return true ;24 }

Figure III.6. File parsing under CrashReporter

1 private void sendReport ( F i l e minidumpFile , Map<Str ing , Str ing> extras , F i l e e x t r a sF i l e ) {2 f ina l CheckBox includeURLCheckbox = (CheckBox ) findViewById (R. id . i n c l u d e u r l ) ;3 S t r ing spec = ext ra s . get (SERVER URL KEY) ;4 . . .5 try {6 URL ur l = new URL( spec ) ;7 HttpURLConnection conn = (HttpURLConnection ) u r l . openConnection ( ) ;8 . . .9 i f ( Bui ld .VERSION.SDK INT >= 16 && includeURLCheckbox . isChecked ( ) ) {

10 sendPart ( os , boundary , ”Android Logcat ” , readLogcat ( ) ) ;11 }12 . . .13 s endF i l e ( os , boundary , MINI DUMP PATH KEY, minidumpFile ) ;14 . . .15 i f ( conn . getResponseCode ( ) == HttpURLConnection .HTTP OK) {16 F i l e submittedDir = new F i l e ( g e tF i l e sD i r ( ) , SUBMITTED SUFFIX) ;17 . . .18 St r ing c ra sh id = responseMap . get ( ”CrashID ” ) ;19 F i l e f i l e = new F i l e ( submittedDir , c r a sh id + ” . txt ” ) ;20 FileOutputStream f o s = new FileOutputStream ( f i l e ) ;21 f o s . wr i t e ( ”Crash ID : ” . getBytes ( ) ) ;22 f o s . wr i t e ( c ra sh id . getBytes ( ) ) ;23 f o s . c l o s e ( ) ;24 }25 . . .26 }27 . . .28 }

Figure III.7. sendReport under CrashReporter