New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 621893 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Security: NTLM authentification is used when browing in private mode without furthe notice

Reported by timo.wi...@gmail.com, Jun 21 2016

Issue description

VULNERABILITY DETAILS
If you start a browser session in private mode and access a server which requires NTLM authentification. Chrome happily sends your current NT-Credentials, so the remote server is able to identify your client, even if you are using private mode.

VERSION
Chrome Version: All versions which support NTLM auth.
Operating System: Win 7

REPRODUCTION CASE
Setup a webserver which asks for NTLM authentification. In my case i used Apache on Windows with mod_authn_ntlm.so. Access the "secured" page with chrome running in private mode.

Download mod_authn_ntlm from https://github.com/YvesR/mod_authn_ntlm/tree/master/bin


Configure Apache on Windows:

LoadModule auth_ntlm_module modules/mod_authn_ntlm.so

<Directory "S:/path/to/htdocs/secured">
    AuthName "Hermes Data"
    AuthType SSPI
    NTLMAuth On
    NTLMAuthoritative On

    require valid-user
</Directory>

place a script into /secured which echos $_SERVER["REMOTE_USER"]

access http://yourserverhostname/secured

Chrome transmits your NT-Credentials and they are displayed
 
Owner: cbentzel@chromium.org
+cbentzel: could you help triage this?
Components: Internals>Network>Auth Enterprise
Project Member

Comment 3 by ClusterFuzz, Jun 22 2016

Status: Assigned (was: Unconfirmed)
Project Member

Comment 4 by ClusterFuzz, Jun 25 2016

Labels: Missing_Severity-1 Missing_Impact-1
Labels: -Missing_Severity-1 -Missing_Impact-1 Security_Impact-Stable Security_Severity-Low
I'm going to tentatively say that this is more a privacy problem than a security issue, so assigning labels as such. Once I hear more from an expert, we can reassess.
Project Member

Comment 6 by sheriffbot@chromium.org, Jun 25 2016

Labels: Pri-2

Comment 7 by ta...@google.com, Jul 13 2016

Labels: OS-Windows

Comment 8 by ta...@google.com, Jul 13 2016

Labels: -OS-Windows OS-All
Labels: -Type-Bug-Security -Pri-2 -Restrict-View-SecurityTeam -Security_Severity-Low -Security_Impact-Stable Review-Privacy Pri-3 Type-Bug
Sorry for missing this. I'll mark as privacy. The same case also applies for Negotiate (likely) where we will use machine login credentials if possible.

I am not sure where this falls under incognito expectations actually.

This also isn't a security bug so removing those labels and restricts.
Cc: battre@chromium.org
battre: Can you (or someone on privacy team) take a quick look at this? I'm tempted to mark WontFix as I don't see this counter to the goals of incognito, but I could be wrong.

In practice, even if we turned off Integration Authentication in incognito, my guess is most would end up typing same account for server or proxy auth.
Hm, I have little experience with NTLM. I think we should try to follow existing precedents.

Would you rather consider this a part of your proxy configuration, which is governed by the OS? In that case, incognito mode should follow regular mode and not ask for credentials again.

Is this rather like HTTP Auth towards a specific domain? In that case I think that incognito mode should ask you to authenticate again.
It could be used both for a specific domain (server authentication) or for a proxy (proxy authentication).

The real issue here is IWA and automated credentials I think for expectations. I could imagine that for any incognito network requests we require the user to enter credentials in the login prompt. I could also imagine the annoyance of this not being worth the tradeoff (particularly for proxy auth) as the user is likely to re-enter the credentials they signed into the machine with except in some circumstances.
Labels: LaunchIssue-NA
Project Member

Comment 14 by chrome-privacy-bot@chromium.org, Nov 14 2016

Dear cbentzel,

This review has now been inactive for over 3 days. Could you please take appropriate steps to finish the review?

Your friendly privacy review bot.
Status: WontFix (was: Assigned)
I'm going to mark this wontfix. I think of this as tied closer to the OS. Privacy team - if you feel strongly that this should be different I'm happy to reopen.

Sign in to add a comment