Proxy authentication with Auth-Cookies not working anymore

RESOLVED WORKSFORME

Status

()

Core
Networking: Cookies
RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: hannes.schachinger, Unassigned)

Tracking

({dev-doc-complete, regression, site-compat})

35 Branch
x86_64
Windows 7
dev-doc-complete, regression, site-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox35+ wontfix, firefox36- affected, firefox37- affected, firefox38- affected, firefox-esr31-, firefox-esr38-)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150108202552

Steps to reproduce:

I opened an corporate-internal site.

Normally the HTTP-Request gets modified by the proxy so that my credentials will be sent to the server i want to access and i get an auth-cookie back.


Actual results:

I had to enter my username and password.


Expected results:

The site should've opened without a prompt to enter a username and password.
(Reporter)

Comment 1

3 years ago
I believe this problem is a direct impact from this bug-fix in the new Firefox-version: https://www.mozilla.org/de/security/advisories/mfsa2015-04/ 

It could probably affect many corporations with LDAP+proxy or any other proxy-authentication.
Severity: normal → enhancement
Component: Untriaged → Security
Keywords: csectype-other
Whiteboard: proxy, authentication, cookie

Updated

3 years ago
Duplicate of this bug: 1121890

Updated

3 years ago
Severity: enhancement → normal
Component: Security → Networking: Cookies
Keywords: csectype-other
Product: Firefox → Core
Whiteboard: proxy, authentication, cookie

Comment 3

3 years ago
[Tracking Requested - why for this release]:
From the number of issues with proxy/ntlm/kerberos auth, seems like we should keep an eye on this for 35 and/or the ESR releases
(see also bug 1108971 and bug 1121843 - not sure they're related to this bug (probably not) but their combination might significantly impact the release on enterprise)
tracking-firefox35: --- → ?
tracking-firefox-esr31: --- → ?

Comment 4

3 years ago
Patrick, is the theory in comment #1 likely correct? Is there a way to distinguish these "legitimate" and "insecure" cookie-setting things?
Flags: needinfo?(mcmanus)
Blocks: 1121950
Blocks: 1095859
Flags: needinfo?(mcmanus)
There is(In reply to :Gijs Kruitbosch from comment #4)
> Patrick, is the theory in comment #1 likely correct? 

probably.

> Is there a way to
> distinguish these "legitimate" and "insecure" cookie-setting things?

I don't know that its legitimate :) (but many illegitimate things are common on the internet). There is no such thing as a hop to hop cookie, so any cookie is part of the origin cookie set.. allowing annotation of it actually opens up some well known security attacks (for instance you can push even secure https only cookies for the same domain out of the cookie set by overfilling it from the http context.) A proxy could even do this quite by accident in ff 34 (because there is no separation between the origin cookies and the proxy's cookies).

I suppose we can consider reverting it if the interop problem becomes too much - but nothing comes to mind for how to tweak it.
Tracking so we can keep an eye on this though at this point it's not clear we'd have a low-risk uplift that could go into a 35 dot release or chemspill.  Is there a possible backout that could return us to a known-good state?  Who's a good assignee for this?  Patrick?
status-firefox35: --- → affected
status-firefox36: --- → affected
status-firefox37: --- → affected
status-firefox38: --- → affected
tracking-firefox35: ? → +
tracking-firefox36: --- → +
tracking-firefox37: --- → +
tracking-firefox38: --- → +
Flags: needinfo?(mcmanus)
the issue here is just whether we think closing the vulnerability from comment 1 is worth while. It was assessed sec-moderate.

Afaict other browsers remain exposed to the problem.

if we wanted to revert it would be an easy low risk patch.

maybe dan would have an opinion.
Flags: needinfo?(mcmanus)
Flags: needinfo?(dveditz)
What do Chrome and IE do in these cases? Maybe we jumped to conclusions that bug 1095859 was claiming Firefox was uniquely wrong. Maybe the fix is mostly correct but needs to account for some edge case in this particular proxy set up. The case we fixed seemed wrong and was easy to demonstrate in a test setup. I'm nervous about jumping into trying to fix this particular case when we're just guessing at what's wrong: we have no packet capture, don't know what kind of server or auth is at the far end, don't know what software the proxy is running or what it's doing to the traffic.

How did the proxy get the reporter's credentials to pass them along if he didn't have to enter credentials before? Was there an unstated Proxy Authenticate dialog he filled in first and he's complaining of having to log in a second time? Or is there some magic windows domain silent login that's already happened?
Flags: needinfo?(dveditz)
1- I think there is also a chance this is actually misdiagnosed and is part of the windows auth alias bug. 1108971 

2 - It sounds like Dan votes "no" on reversion without more details from the reporter. I would tend to agree - especially if dups don't start piling up.

Hannes. Can you please try a nightly build (nightly.mozilla.org)and retest? That has the bug from #1 in it fixed. (If it fails let us know the info from about:buildconfig so I can confirm it was in the build)

Hannes, wrt#2 if you can provide and of the information dan mentions in comment 8 that would be helpful. You can mark attachments as secure in bugzilla if that helps (it limits the audience)
Flags: needinfo?(hannes.schachinger)
(Reporter)

Comment 10

3 years ago
I think you are right with your first point.

I read the bug and it sounds pretty like my problem, so I think I misdiagnosed this. If you agree, I would like this bug to be closed and / or pointed to bug #1108971.

Regarding the nightly build: it didn't work with the nightly, here is the info from about:buildconfig:

Build Machine

B-2008-IX-0097


Source

Built from https://hg.mozilla.org/mozilla-central/rev/0c454540fc2b


Build platform

target
x86_64-pc-mingw32


Build tools

Compiler 	Version 	Compiler flags
cl 	1800 	-TC -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -FS -wd4244 -wd4267 -wd4819 -we4553
cl 	1800 	-TP -nologo -D_HAS_EXCEPTIONS=0 -W3 -Gy -FS -wd4251 -wd4244 -wd4267 -wd4345 -wd4351 -wd4482 -wd4800 -wd4819 -we4553 -GR- -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 -Oi -Oy-


Configure arguments

--target=x86_64-pc-mingw32 --host=x86_64-pc-mingw32 --enable-crashreporter --enable-release --enable-update-channel=nightly --enable-update-packaging --enable-jemalloc --with-google-api-keyfile=/c/builds/gapi.data --with-google-oauth-api-keyfile=/c/builds/google-oauth-api.key --with-mozilla-api-keyfile=/c/builds/mozilla-desktop-geoloc-api.key --enable-signmar --enable-profiling --enable-js-diagnostics
Flags: needinfo?(hannes.schachinger)

Comment 11

3 years ago
So, does this mean that the fix for CVE-2014-8639 doesn't at all impact proxy authentication and in fact was caused in all cases by the other bug?

In that case this vulnerability can remain patched without risk or loss of functionality. After all, we only block the cookie if it's a 407 so other proxy use would still be safe, unless I misread the patch?
(In reply to hannes.schachinger from comment #10)
> I think you are right with your first point.
> 
> I read the bug and it sounds pretty like my problem, so I think I
> misdiagnosed this. If you agree, I would like this bug to be closed and / or
> pointed to bug #1108971.
> 

I would do that if the test build resolved your problem, unfortunately it didn't :(

> Regarding the nightly build: it didn't work with the nightly, here is the
> info from about:buildconfig:
> 
> Built from https://hg.mozilla.org/mozilla-central/rev/0c454540fc2b
> 

So I just confirmed that cset 0c454540fc2b does contain the patch for 1108971, so I would have expected your test case to work if this was just a dup (1108971 has been verified by a number of reporters).

I think an HTTP log using a copy of firefox that does not give you a problem (i.e. firefox 34) would let me see your use case.

you can make a log from the directions here https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

and you can mark the attachment private when uploading

Updated

3 years ago
Keywords: dev-doc-needed, regression, site-compat
https://developer.mozilla.org/en-US/Firefox/Releases/35/Site_Compatibility#Security
https://twitter.com/FxSiteCompat/status/557623945248387072
Keywords: dev-doc-needed → dev-doc-complete
Updating tracking flags so this is on our radar for esr38 - would be great to know for sure what the expected behaviour should be for FF38 which is the next base for ESR.
status-firefox35: affected → wontfix
tracking-firefox-esr38: --- → ?
Hannes, any chance we could get an HTTP log from you using an older, working copy of Firefox? (see comment 12).  We'd love to be able to fix this bug.
Flags: needinfo?(hannes.schachinger)
mcmanus/jduell - Any way to proceed without the log? Do we know any other site that can reproduce the issue?
Flags: needinfo?(mcmanus)
Flags: needinfo?(jduell.mcbugs)
I'm not aware of any other instance of this issue - and it is on the release channel.. while that will have less per-capita proxy browsing than ESR, it has certainly shown us issues in the past that beta does not.

Given that there aren't other reports (at least that have surfaced to me) then its plausible this is indeed a dup of the more prevalent fixed issue and something went wrong with the validation in comment 10.

Its not obvious how to proceed - without the log from 15 containing before and after results.
Flags: needinfo?(mcmanus)
If that's the case, I suggest that we give Hannes a bit longer to respond. If we don't get any useful data to help move this forward, let's assume that this is a dup and has already been fixed.
Flags: needinfo?(jduell.mcbugs)
(Reporter)

Comment 19

3 years ago
Sorry, I didn't watch the bug for a time...

I have had a conversation about the bug with a colleague and, as I mentioned in a former comment, I have misdiagnosed this issue.

It was a kerberos-problem, which is already solved in the latest firefox. Everything works now, sorry for not responding earlier.

This bug can be closed as it is clearly a misinterpretation of the problem from me and is already solved in the latest stable firefox build.

Thanks for your help and trying to fix this issue. :)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(hannes.schachinger)
Resolution: --- → WORKSFORME
Untracking this from Hannes' answer in comment 19.
tracking-firefox36: + → -
tracking-firefox37: + → -
tracking-firefox38: + → -
tracking-firefox-esr31: ? → -
tracking-firefox-esr38: ? → -
You need to log in before you can comment on or make changes to this bug.