Mozilla support cache poisoning to open redirect



3 years ago
2 years ago


(Reporter: yaaboukir, Unassigned)


(5 keywords)

csectype-dos, csectype-spoof, sec-moderate, wsec-other, wsec-redirect
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(Not tracked)



(1 attachment)



3 years ago

I discovered a security vulnerability that allows an attacker to poison any legitimate user cache and redirect him/her to malicious websites designed to hijack the user's login credentials.

At first, I noticed a minor bug that was leading to an invalid redirection. When you add a slash to the last part of the URL such as : (Bug 1)

You will be redirected to https://en-Us//Evil.Com  which is not exploitable so far.

I also found that we can set arbitrary languages via: (Bug 2)

So when you browse to you will be redirect to :

Finally, I chained both bugs (1 and 2) to craft a successfull poisoning and redirect attack. When we send our victim the following link :

The language will be set to / so when the victim browse to he/she will be redirected to and due to our first bug the victim will be taken to

Notice that everytime the victim reloads he/she will automatically be redirect to our phishing/malicious page.

Final Exploitation : An attacker can simply post the following link in a support discussion or comment: once any SUMO user clicks on it, his/her browser cache will be poisoned, consequently the user will be redirected to each time he/she visits SUMO platform.

Proof Of Concept : (Video publicly unlisted)

Kind regards
Confirmed. Made SUMO impossible to reach until the cache was cleared.
Mentor: abillings, dveditz, me+bugzilla, rforbes, willkg
Ever confirmed: true
Flags: sec-bounty?
Keywords: csectype-dos, csectype-spoof
Thank you for reporting, Yassine, very nice catch. 

David, who should the security point of contact be for sumo? Could you please update our contact spreadsheet?
Flags: needinfo?(djst)
Keywords: sec-moderate, wsec-other, wsec-redirect

Comment 3

3 years ago
I have taken a look over some sec bugs and noticed that is in charge of SUMO security if that might help get this bug patched ASAP.
I'm not working on Sumo anymore. I'll redirect this to Giorgos, who is more fit to work on this right now.

Giorgos: I'd start by looking at the LocaleUrlMiddleware[0]. That is what is reading the locale from the URL and the lang query parameter. It also uses a class called Prefixer[1] to actually modify the URLs. Beyond that, I never worked on the language redirects, so I'm not sure where to look next.

Flags: needinfo?(djst) → needinfo?(giorgos)


3 years ago
Hardware: Unspecified → Other
Flags: needinfo?(giorgos)
Created attachment 8757207 [details] [review]
Only redirect if lang is in SUMO_LANGUAGES

Comment 6

3 years ago
The fix seems to be resolving the issue. 
I hope it will be deployed to production environment soon.
The fix seems to work in STG, but the behavior mentioned as bug 1 is still reproducible.

Comment 8

3 years ago
You are right! The first bug is still reproducible :

> (Bug 1)
>You will be redirected to https://en-Us//Evil.Com
Indeed but without the first bug this cannot be exploited in a meaningful manner. I'll go ahead and deploy those changes today.
OK. Let's mark this bug as FIXED than and make a new clone for the behavior described as bug 1, so we won't loose it. If you won't have time to look at it, I might give it a try during the weekend or the next week.
Have you successfully deployed the fix, Giorgos?
Flags: needinfo?(giorgos)
No, we're currently blocked. I'll update when I have more info.
Flags: needinfo?(giorgos)
Blocks: 836577
Although we don't normally award bounties for denial of service bugs, this one is clever and a nice find.
Flags: sec-bounty? → sec-bounty+
What are we being blocked by now? How can I help?
Your offer is appreciated. The whole team is in London these days and things move extremely slowly on this front. Please hang tight.
This is finally now on production. Yassine can you please confirm that this is fixed?
Last Resolved: 2 years ago
Flags: needinfo?(yaaboukir)
Resolution: --- → FIXED

Comment 17

2 years ago
The first bug is still reproducible : (Bug 1)
Yes, but the security issue needs both. So without the second bug you cannot poison the cache, correct?

Comment 19

2 years ago
Correct. The cache poisoning is no longer possible in this case ;)
Great! thanks again for reporting.
Yeah, Kitsune is not vulnerable this way now, but still the first issue should be fixed. Close this bug and resolve the first issue separately later?


2 years ago
Flags: needinfo?(yaaboukir)
Verified per comment #19
Removing the security flag, the vuln is fixed and the issue remaining is not a security issue
Group: websites-security
Flags: needinfo?(mstanke)
Michal - This bug is closed, if you want to track the remaining issue, best to track it in a new bug


2 years ago
See Also: → bug 1256972
You need to log in before you can comment on or make changes to this bug.