1046421 - (CVE-2015-4515) Information disclosure vulnerability in Firefox via NTLM based HTTP authentication feature

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Tim Brown]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

Steps to reproduce:

I have no idea how seriously this bug will be treated however Firefox/Chrome (Multiplatform) along with Safari (OS X/iOS), Web Browser (BlackBerry) and IE (Windows) disclose the hostname and (in some cases the Windows domain) via NTLM based HTTP authentication when sending type 3 messages as part of the authentication exchange. 
NB: I've only approached Google so far, some help with co-ordination might be required, if it is deemed worth fixing.

An example URL to a web server capable of triggering this flaw can be made available on request, however I believe the bug is simple enough that it can easily be spotted in the source. I'm guessing populate that Firefox simply populates the Workstation field with the hostname of the system. By comparison, the original KHTML source tree is not affected (since that uses the hardcoded "WORKSTATION" value).


Actual results:

This can allow users to be tracked across the Internet. Some observations:

* The exploit can be triggered silently
* The exploit works irrespective of whether JavaScript is enabled
* The exploit works even in privacy mode
* The exploit can be triggered even if the user is behind a firewall and/or proxy
* The exploit can be utilised to aid in unmasking VPN and/or TOR users


Expected results:

Type 3 messages sent by Firefox should not disclose the users real hostname and/or Windows domain.

Comment 1

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

I believe this is per the spec for NTLM as a type 3 response contains the client's responses to the Type 2 challenge, which demonstrate that the client has knowledge of the account password without sending the password directly. The Type 3 message also indicates the domain and username of the authenticating account, as well as the client workstation name. As such sending this over HTTP would allow this information to be read as neither the transport of HTTP nor the message itself encrypt this.

Also as NTLM v1 is insecure it is preffed off in Firefox by default (network.negotiate-auth.allow-insecure-ntlm-v1).
Good discussions as to why NTLM v1 should not be used where security is expected can be found in bug 828183

Unless there is other supporting evidence that a fix here is required it's better to just not use this protocol, especially not over HTTP. As such I'm inclined to WONT-FIX this bug unless there is strong evidence a fix should be implemented.

Comment 2

[Tim Brown]

Curtis,

I'm not talking about a passive attack by listening on the network. I'm talking about the ability to actively poll for it, without the user being aware that it has occurred. basically, I can create an iframe with a src of http[s]://test:test@somethingicontrol/ and then by the way I respond, I can cause the browser to disclose this information. Normally if I ask for NTLM creds then the browser would prompt the user for them (assuming no existing trust relationship), however the use of a dummy username:password in the URL combined with the use of an iframe means that the negotiation occurs silently. I'm in two minds myself, on the one hand it's a tiny info disclosure, but the scale and implications on certain classes are interesting. As discussed KHTML simply sends "WORKSTATION" with no obvious side effects.

Tim

Comment 3

[Tim Brown]

So, to cross pollinate, Google's initial response was similar but when I added the additional detail (as per comment 2), we began to kick around some ideas to resolve it. Unlike pretty much every browser out there, Safari on iOS picked it up (at least on jframes) due to the embedded credentials. Do you guys have any stats on how many users use XHR/iframes with URLs that contain embedded credentials? Could you perhaps block on that instance, if not in response to the issue of NTLM based authentication more generally?

Comment 4

[Tim Brown]

Just to let you guys know, we have now contacted BlackBerry, Microsoft and Apple's p[roduct security teams.

Comment 5

[Mike Perry]

I am looking at the source now. It looks like GenerateType3Msg() in security/manager/ssl/src/nsNTLMAuthModule.cpp is the offending function (https://mxr.mozilla.org/mozilla-esr24/source/security/manager/ssl/src/nsNTLMAuthModule.cpp#630)? Seems simple enough for us to hardcode the string there to be 'localhost' or 'WORKSTATION' for Tor Browser, unless there is a pref we could use instead to disable either this bit, or all of NTLM.

If we do decide to patch this ourselves, how would Mozilla like to coordinate?

Comment 6

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

So this should already disabled by default via "network.negotiate-auth.allow-insecure-ntlm-v1 = false" as mentioned in bug 828183. You could take the extra step of setting "network.negotiate-auth.allow-insecure-ntlm-v1-https = false" as well. While NTLMv1 is insecure the behavior here is in-line with the spec and I believe some apps do use the machine name legitimately, so changing this could have some wide ranging side effects for users. Given this is a low severity threat making a general spec noncompliant change is not something I'm convinced we need to do. 

mcmanus - what's your take on this?

Comment 7

[Patrick McManus [:mcmanus]]

I'm going to defer to honza here - he understands ntlm better.

Comment 8

[Honza Bambas (:mayhemer)]

On Windows we use the system API to build the response, so there is no or a little control over the workstation name sec buffer (we could modify the buffer, but that sounds to me like not a really good idea).

On non-windows, we by default don't have an NTLM/Nego authenticator by now.  However, also according the suggested preference changes, we are already preparing NTLMv2 support that will reenable NTLM on non-win and the code we own that puts the name to the response will run again.

We could enforce the "you are sending embedded credentials in URL to site x.y, continue?" for NTLM subresources (currently we do that only for top level loads).  Not an ideal solution, tho.

Other option: we have a preference that lists "trusted URIs" i.e. origins the default credentials can be send to (used actually only on non-win platforms).  We could use this list to decide whether to send the workstation name security buffer (it's optional).  This way we can preserve compatibility to some level (tell people to set a pref in case of problems) and also solve the global tracking issue.  

We could also send it only to private addresses (192.256.x.x etc).

Comment 9

[Mike Perry]

Ok, so it sounds like a correct fix would involve a number of as-yet undecided new prefs. For Tor Browser, we will likely just set network.negotiate-auth.allow-insecure-ntlm-v1-https = false for now, as this issue is much higher priority for us, and I doubt many/any of our users need NTLM over Tor.

Tim - are you able to confirm that this pref prevents all http and https NTLM auth attempts that include this hostname?

Honza - Is there a bug we can also track for the NTLMv2 support? Is there anything else we need to be aware of with this suggested pref workaround?

Comment 10

[Tim Brown]

I will try and check ASAP.

Comment 11

[Honza Bambas (:mayhemer)]

(In reply to Mike Perry from comment #9)
> Ok, so it sounds like a correct fix would involve a number of as-yet
> undecided new prefs. For Tor Browser, we will likely just set
> network.negotiate-auth.allow-insecure-ntlm-v1-https = false for now, as this
> issue is much higher priority for us, and I doubt many/any of our users need
> NTLM over Tor.
> 
> Tim - are you able to confirm that this pref prevents all http and https
> NTLM auth attempts that include this hostname?

It will still allow use SSPI (direct APIs) on windows, that is always used.  I don't know whether SSPI fills in the workstation name security buffer.

One way (you will probably not like) how to completely disable NTLM is to force generic (set the "network.auth.force-generic-ntlm" to true) and switch to FIPS mode.  The pref at true will prevent system API use and FIPS mode will disable the generic/internal module.  Thus no NTLM authenticator will be found to response to the challenge.

> 
> Honza - Is there a bug we can also track for the NTLMv2 support? Is there
> anything else we need to be aware of with this suggested pref workaround?

Yep, bug 423758.

Comment 12

[Mike Perry]

(In reply to Honza Bambas (:mayhemer) from comment #11)
> (In reply to Mike Perry from comment #9)
> > Ok, so it sounds like a correct fix would involve a number of as-yet
> > undecided new prefs. For Tor Browser, we will likely just set
> > network.negotiate-auth.allow-insecure-ntlm-v1-https = false for now, as this
> > issue is much higher priority for us, and I doubt many/any of our users need
> > NTLM over Tor.
> > 
> > Tim - are you able to confirm that this pref prevents all http and https
> > NTLM auth attempts that include this hostname?
> 
> It will still allow use SSPI (direct APIs) on windows, that is always used. 
> I don't know whether SSPI fills in the workstation name security buffer.
> 
> One way (you will probably not like) how to completely disable NTLM is to
> force generic (set the "network.auth.force-generic-ntlm" to true) and switch
> to FIPS mode.  The pref at true will prevent system API use and FIPS mode
> will disable the generic/internal module.  Thus no NTLM authenticator will
> be found to response to the challenge.

Ok, I think instead I will just patch nsHttpNTLMAuth::ChallengeReceived() to always return NS_ERROR_ABORT. This seems like it should be sufficient to completely disable NTLM for Tor Browser.

I am also looking at nsHttpNegotiateAuth::ChallengeReceived() and am wondering if I should do the same there? Negotiate auth can end up as a couple different underlying Kerberos/SPNEGO auth types. Do we know for sure if those *can't* disclose hostname/machine info?

In both cases, either NTLM auth or Negotiate auth should primarily be deployed on internal enterprise networks, and are unlikely to be seen by Tor users, correct?

Comment 13

[Honza Bambas (:mayhemer)]

(In reply to Mike Perry from comment #12)
> (In reply to Honza Bambas (:mayhemer) from comment #11)
> > (In reply to Mike Perry from comment #9)
> > > Ok, so it sounds like a correct fix would involve a number of as-yet
> > > undecided new prefs. For Tor Browser, we will likely just set
> > > network.negotiate-auth.allow-insecure-ntlm-v1-https = false for now, as this
> > > issue is much higher priority for us, and I doubt many/any of our users need
> > > NTLM over Tor.
> > > 
> > > Tim - are you able to confirm that this pref prevents all http and https
> > > NTLM auth attempts that include this hostname?
> > 
> > It will still allow use SSPI (direct APIs) on windows, that is always used. 
> > I don't know whether SSPI fills in the workstation name security buffer.
> > 
> > One way (you will probably not like) how to completely disable NTLM is to
> > force generic (set the "network.auth.force-generic-ntlm" to true) and switch
> > to FIPS mode.  The pref at true will prevent system API use and FIPS mode
> > will disable the generic/internal module.  Thus no NTLM authenticator will
> > be found to response to the challenge.
> 
> Ok, I think instead I will just patch nsHttpNTLMAuth::ChallengeReceived() to
> always return NS_ERROR_ABORT. This seems like it should be sufficient to
> completely disable NTLM for Tor Browser.
> 
> I am also looking at nsHttpNegotiateAuth::ChallengeReceived() and am
> wondering if I should do the same there? 

To both is correct.

> Negotiate auth can end up as a
> couple different underlying Kerberos/SPNEGO auth types. Do we know for sure
> if those *can't* disclose hostname/machine info?

I cannot say for sure, sorry.  But by the changes you suggest above you disable them all.

> 
> In both cases, either NTLM auth or Negotiate auth should primarily be
> deployed on internal enterprise networks, and are unlikely to be seen by Tor
> users, correct?

Definitely.

Comment 14

[Tim Brown]

Not sure if Mozilla were kept in the loop but Tor have landed their fix:

https://blog.torproject.org/blog/tor-browser-365-and-40-alpha-2-are-released

Assume you'll complete your risk assessment and patch/allocate a CVE as necessary?

Comment 15

[Andrew Bartlett]

The workstation parameter here is used by the server in some instances, but those are generally the single-sign-on case.

A windows DC has a parameter userWorkstations, which contains the names of workstations the user is permitted to log in from.  If the value sent here is not in that list, then the user should be denied at the NTLM login stage.

Now, this is a crazy mechanism, without validation (as is the case here).  It made sense sort of for interactive logons where the trust relationship between the workstation and the DC gave this some value, but it is sent for all NTLM logons, and in Windows 2000 for AD they even extended Kerberos to have the client encode it in the addresslist for the ticket. 

If we decide we care, another option would be to present it in the NTLM logon dialogue.

In terms of the risks in the broader case, that is what can Negotiate send in general, the biggest leaks are:

 - Kerberos would leak the name of any Negotiate-enabled site also present in the preference to your KDC, if you have a ticket.  This list is empty by default, but Ubuntu sets it to all https:// sites.
 - Automatic NTLM can of course leak your username/hostname/password-response (for later brute force or reflection) as above.

Both these protocols really are designed for inside the corporate network, and were created in a different age of privacy thought.

Comment 16

[Tim Brown]

Do Mozilla have an ETA on whether they are intending to address this in a subsequent release of Firefox? It has been 2 months since we made the initial report.

Comment 17

[Andrew Bartlett]

Attachment: 0001-Bug-1046421-Do-not-disclose-the-system-hostname-via-.patch

Setting this to a fixed value can have an impact on intranet use.  While I had hoped that folks where not using userWorkstations in AD, bugs like this wouldn't be FAQs otherwise:

https://confluence.atlassian.com/display/CONFKB/Unable+to+Log+in+Because+of+userWorkstations+Attribute+in+Active+Directory

Regardless, I'll here upload a tested patch to hardcode the value to localhost.

This works with or without my current work on Bug 423758

Comment 18

[Tim Brown]

Since other vendors were less than responsive, and since the TOR folk have issued a patch, we're moving to disclose in 7 days at our discretion. I'm sorry to drop you in it, but given this is cross-platform. cross-browser I feel we have little choice.

Comment 19

[Honza Bambas (:mayhemer)]

Comment on attachment 8505926 [details] [diff] [review]
0001-Bug-1046421-Do-not-disclose-the-system-hostname-via-.patch

Review of attachment 8505926 [details] [diff] [review]:
-----------------------------------------------------------------

Patches to the NTLM code are always problematic.  It will take four cycles to arrive to the Release channel.  Only then we'll know what all we break.

Not sure sending 'localhost' only to non-local networks is the way since some corporate nets can IMO (correct me if I'm wrong) be Internet accessible and requiring NTLM with the correct hostname disclosed anyway.

Still, I'd slightly more prefer to send 'localhost' to only (!IsIPAddrLocal(addr) && !IsLoopBackAddress(addr)) addresses.  Bad thing is that the functions we have right now for this are in netwerk/dns module, so unlinkable to security/manager easily.  But we could introduce a new 'peer-addr-is-private' authentication flag at [1] passed from netwerk code to the authentication code.

[1] http://hg.mozilla.org/mozilla-central/annotate/cadcd47db610/netwerk/base/public/nsIAuthModule.idl#l53

Comment 20

[Tim Brown]

Following discussions with other vendors it has become apparent that a number of them are intending to issue patches to resolve this problem. As a result, we are happy to report that we will extend our period of non-disclosure until the start of 2015. We will be in touch at the start of the new year to discuss current status.

Comment 21

[Andrew Bartlett]

Some further thoughts:
 - Exploiting this in the wild to extract a user's hostname would require that they enter the username/password, or at least see the warning from Bug #232567. 

 - Most users restricted by allowedWorkstations would be using or be able to the SSPI single-sign-on mechanism, not this one, to access a restricted website.  It really only makes sense for desktop-matching credentials anyway. 

 - We could make the string "localhost" instead a pref, and so allow users to specify their workstation name there, if they really need it.  default should probably be all-caps WORKSTATION to match what some  other NTLM clients use.

Comment 22

[Andrew Bartlett]

Honza,

Would this (a pref) be a reasonable approach for dealing with this, with minimal pain? 

Thanks,

Comment 23

[Honza Bambas (:mayhemer)]

Sounds good.

Comment 24

[Andrew Bartlett]

Attachment: A new patch using a pref, as requested

New patch using a pref, as requested.

Comment 25

[Andrew Bartlett]

Comment on attachment 8622273 [details] [diff] [review]
A new patch using a pref, as requested

Tim,

Are you happy with this as a fix for your information disclosure issue?

Thanks,

Andrew Bartlett

Comment 26

[Honza Bambas (:mayhemer)]

Comment on attachment 8622273 [details] [diff] [review]
A new patch using a pref, as requested

Review of attachment 8622273 [details] [diff] [review]:
-----------------------------------------------------------------

::: security/manager/ssl/nsNTLMAuthModule.cpp
@@ +626,3 @@
>    //
> +  rv = prefs->GetCharPref("network.generic-ntlm-auth.workstation",
> +			  getter_Copies(hostBuf));

please don't use the service (also remove do_GetService(NS_PREFSERVICE_CONTRACTID)) but use Preferences:: as in InitTest().  See http://hg.mozilla.org/mozilla-central/annotate/be81b8d6fae9/modules/libpref/Preferences.h#l185

Please also assert you are on the main thread:

MOZ_ASSERT(NS_IsMainThread());

Comment 27

[Tim Brown]

"WORKSTATATION"?

Looks good other than that. It's pretty much what KDE do, except with Konqueror you can't change it.

Tim

Comment 28

[Tim Brown]

Comment on attachment 8622273 [details] [diff] [review]
A new patch using a pref, as requested

Review of attachment 8622273 [details] [diff] [review]:
-----------------------------------------------------------------

Andrew,

Sorry about that, I commented in bug, rather than here :/

Anyway:

"WORKSTATATION"?

Looks good other than that. It's pretty much what KDE do, except with Konqueror you can't change it.

Tim

Comment 29

[Douglas Bagnall]

Attachment: A new version of Andrew Bartlett's patch incorporating review feedback.

Here we recall how to spell WORKSTATION and use the Preferences:: module for accessing a preference.

Comment 30

[Honza Bambas (:mayhemer)]

Comment on attachment 8638276 [details] [diff] [review]
A new version of Andrew Bartlett's patch incorporating review feedback.

You need a sec approval first.

Comment 31

[Honza Bambas (:mayhemer)]

Comment on attachment 8638276 [details] [diff] [review]
A new version of Andrew Bartlett's patch incorporating review feedback.

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
  This is a privacy information leak, that can only be used to track users w/o ability to opt out.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
  Very much, the commit message must be adjusted.

Which older supported branches are affected by this flaw?
  All of them I think

If not all supported branches, which bug introduced the flaw?
  It's there since ever...

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
  We don't have them, should be easy to create and the patch is generally very low-risk.

How likely is this patch to cause regressions; how much testing does it need?
  Hard to say.  This modifies behavior of NTLM that we always discover only on the Release channel.  So, uplift will just help to discover problem sooner.

Andrew may also help answer how far we should back port.

Comment 32

[Al Billings [:abillings - ex-MoCo]]

Comment on attachment 8638276 [details] [diff] [review]
A new version of Andrew Bartlett's patch incorporating review feedback.

sec-low bugs don't need sec-approval, only sec-high and sec-critical that affect more than trunk.

Comment 33

[Honza Bambas (:mayhemer)]

Attachment: 0001 (updated commit message)

Comment 34

[Andrew Bartlett]

BTW, relevant to this as context is bug 647010 (which I saw with bug 1159584).  I realise cross-origin is not required to disclose, and this only block prompts, but I wanted to link up some of the changes in this area for those looking into this later.

Comment 35

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/147b08201ced

Comment 36

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/bf5fd6a7021e

Comment 37

[Tim Brown]

Will there be a CVE for this from Mozilla? At the moment only TBB and Mozilla have landed fixes but at some stage we'll need to publish our advisory and we'll need a CVE to reference.