Created attachment 8564918 [details] Screenshots.docx User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20150122214805 Steps to reproduce: 1- Access the URL pfs.mozilla.org 2- Intercept the request 3- Change the host header to google.com 4- Observe the 302 redirect response 5- Application redirected to google.com 6- Now access the application pfs.mozilla.org again 7- This time you will observed application automatically gets redirected to google.com Actual results: Its redirecting to google everytime whenever a user tries to open the site pfs.mozilla.org Expected results: Ideally it should not redirect to google.
Georg, who's responsible for the server-side infra here?
Group: core-security → websites-security
Component: Untriaged → plugins.mozilla.org
Product: Firefox → Websites
Version: 35 Branch → Production
Good question - Benjamin or Schalk might know?
(In reply to Georg Fritzsche [:gfritzsche] from comment #2) > Good question - Benjamin or Schalk might know? I have absolutely no idea. I thought pfs was retired :/ I am responsible for the front end part of mozilla.org/plugincheck and to some extent the back-end at plugins.mozilla.org but unfortunately cannot offer any advise in terms of pfs.m.o
(In reply to Schalk Neethling [:espressive] from comment #3) > (In reply to Georg Fritzsche [:gfritzsche] from comment #2) > > Good question - Benjamin or Schalk might know? > > I have absolutely no idea. I thought pfs was retired :/ Ditto. If the server is effectively doing open proxy stuff, can we just shut it down? :-\ Benjamin?
(In reply to Schalk Neethling [:espressive] from comment #3) > (In reply to Georg Fritzsche [:gfritzsche] from comment #2) > > Good question - Benjamin or Schalk might know? > > I have absolutely no idea. I thought pfs was retired :/ Bug 836415 killed it on 35. ESR is still on 31 now.
wclouser is the closest person I know; this is part of the AMO codebase, though run on a separate server IIRC. I'd like to keep PFS running until we retire ESR31, unless that's horribly expensive.
Flags: needinfo?(benjamin) → needinfo?(wclouser)
Hi, Let me know if it is a valid issue and you are able to reproduce this issue? Thanks, Nitin
Hi All, Could you please let me know if you think its a valid issue? Thanks, Nitin
I am waiting for the update since long time. Could anyone please update?
Sorry for missing this. I think it's a server configuration issue. I'll needinfo jason. See below for some curl test cases (note the Location responses): clouserw@sunshine:~$ curl -i http://www.mozilla.org -H 'Host: www.google.com' HTTP/1.1 301 Moved Permanently Content-Type: text/html Date: Wed, 25 Mar 2015 17:24:25 GMT Location: https://www.mozilla.org/ Connection: Keep-Alive Content-Length: 0 clouserw@sunshine:~$ curl -i http://pfs.mozilla.org -H 'Host: www.google.com' HTTP/1.1 301 Moved Permanently Content-Type: text/html Date: Wed, 25 Mar 2015 17:24:34 GMT Location: https://www.google.com/ Connection: Keep-Alive Content-Length: 0
Flags: needinfo?(wclouser) → needinfo?(jthomas)
Hi, You are right, from the response we can say that the host header is not being validating and redirecting to injected domain. We can validate this by using whitelist. Below are the few reference links: http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html http://carlos.bueno.org/2008/06/host-header-injection.html http://www.acunetix.com/blog/articles/automated-detection-of-host-header-attacks/
This was a issue in our https-redirect Zeus traffic script we were using only for pfs.mozilla.org. This is now fixed: λ master ~ → curl -i http://pfs.mozilla.org -H 'Host: www.google.com' HTTP/1.1 301 Moved Permanently Content-Type: text/html Date: Wed, 25 Mar 2015 17:48:59 GMT Location: https://pfs.mozilla.org/ Connection: Keep-Alive Content-Length: 0
Perfect, is this eligible for bounty?
I nominated it with the security team. I expect they'll triage it soon.
Assignee: nobody → jthomas
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Since this is/was a back-end service and not a website people would browse, whether or not it's eligible for a bounty depends on how would you use this to attack a Firefox user. Somehow you have to get the user's browser to make a PFS request and inject a Host: header. The browser only uses TLS connections to PFS so a network MITM is unlikely. You could try a cross-site XHR request, but you can't set the Host: header (http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader%28%29-method). If you did, however, manage to poison the cache we might accept plugin installation data returned from the incorrect host, which could be pretty bad for the older (but still supported) ESR-31 versions.
Let me know your decision on this? No doubt this is an issue and also mentioned under the scope. The only difficulty is the execution. So it decreases the severity rating because of the complexity involved.
There's more than the question of complexity, it's can you do it at all in a way that affects a Firefox user (by poisoning the cache)? Just an open redirect on the web is not a bug that would earn a bounty. If you can affect a Firefox user's use of the plugin finder service then we care very much.
Am not sure where exactly this pfs service is being used and thats why the complexity is high but it does not mean that it cant be exploited. Also Low severity bugs have nominal bounty too.
Actually, we don't pay on low security security rated issues. I'll leave the determination to Dan Veditz.
So far we have a bug but you haven't demonstrated a vulnerability. All the content on pfs is served over TLS and in order to trigger this bug you have to MITM the traffic. If you can MITM the TLS traffic you can do cache poisoning and worse without needing this bug at all.
Not exploitable in practice against Firefox users, does not qualify for a bug bounty.
Flags: sec-bounty? → sec-bounty-
You need to log in before you can comment on or make changes to this bug.