1121895 - Proxy authentication with Auth-Cookies not working anymore

Status: RESOLVED WORKSFORME

(Core :: Networking: Cookies, defect)

Description

[hannes.schachinger]

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.

Comment 1

[hannes.schachinger]

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.

Comment 3

[:Gijs (he/him)]

[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)

Comment 4

[:Gijs (he/him)]

Patrick, is the theory in comment #1 likely correct? Is there a way to distinguish these "legitimate" and "insecure" cookie-setting things?

Comment 5

[Patrick McManus [: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.

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

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?

Comment 7

[Patrick McManus [: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.

Comment 8

[Daniel Veditz [: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?

Comment 9

[Patrick McManus [:mcmanus]]

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)

Comment 10

[hannes.schachinger]

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

Comment 11

[Mark Straver]

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?

Comment 12

[Patrick McManus [:mcmanus]]

(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

Comment 13

[Kohei Yoshino [:kohei]]

https://developer.mozilla.org/en-US/Firefox/Releases/35/Site_Compatibility#Security
https://twitter.com/FxSiteCompat/status/557623945248387072

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 15

[Jason Duell]

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.

Comment 16

[Lawrence Mandel [:lmandel] (use needinfo)]

mcmanus/jduell - Any way to proceed without the log? Do we know any other site that can reproduce the issue?

Comment 17

[Patrick McManus [:mcmanus]]

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.

Comment 18

[Lawrence Mandel [:lmandel] (use needinfo)]

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.

Comment 19

[hannes.schachinger]

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. :)

Comment 20

[Liz Henry (:lizzard) (relman/hg->git project)]

Untracking this from Hannes' answer in comment 19.