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

Issue 773505 link

Starred by 2 users

Issue metadata

Status: Duplicate
Merged: issue 677220
Owner: ----
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Security: Chrome for Mac OSX leaks passwords via use of NSTextField

Reported by lady.9j...@gmail.com, Oct 10 2017

Issue description

This template is ONLY for reporting security bugs. If you are reporting a
Download Protection Bypass bug, please use the "Security - Download
Protection" template. For all other reports, please use a different
template.

Please READ THIS FAQ before filing a bug: https://chromium.googlesource.com
/chromium/src/+/master/docs/security/faq.md

Please see the following link for instructions on filing security bugs:
https://www.chromium.org/Home/chromium-security/reporting-security-bugs

NOTE: Security bugs are normally made public once a fix has been widely
deployed.

VULNERABILITY DETAILS
Chrome leaks website passwords as they are entered on the keyboard to other applications on the system that are listening, like malware with keysniffers in their toolkit. Users using Chrome on Mac are vulnerable to password theft from sites accessed while using Chrome.

Mac OSX has a security feature available to prevent other system applications from creating effective event taps and other intercepts on input fields that contain sensitive data. Chrome is using an insecure class to handle secure input.

VERSION
Chrome Version: Current Stable 61.0.3163.117
Operating System: Mac OSX El Capitan and Sierra
REPRODUCTION CASE
To verify that NSSecureTextField is not in use and password intercept is possible. Run the following in a loop while entering a password into a website in chrome.

ioreg -d 1 -k IOConsoleUsers

the output looks like

"IOConsoleUsers" = ({"kCGSSessionOnConsoleKey"=Yes,"kSCSecuritySessionID"=xxx,"kCGSSessionSecureInputPID"=xxx,"kCGSSessionSystemSafeBoot"=xxx,"kCGSSessionIDKey"=xxx,"kCGSSessionUserNameKey"=”xxx"

kCGSSessionSecureInputPID will be present if a process is calling NSSecureTextField. If there is no Secure Input PID, then no application is calling for secure input. Only one process can access secure input at a time.

Please note that if you run this command while terminal (with secure keyboard entry enabled) is in the foreground the Process ID should reflect terminal's process ID.

If you run this command in a loop and try the same test with Firefox on Mac you will see that firefox correctly uses NSSecureTextField to handle passwords for websites and passwords stored in the browser.

To further confirm create your own keylogger through an event tap or any other method and capture website passwords sent through chrome.

https://developer.apple.com/library/content/technotes/tn2150/_index.html

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: [tab, browser, etc.]
Crash State: [see link above: stack trace, registers, exception record]
Client ID (if relevant): [see link above]

 
Components: Blink>Forms>Password
Labels: OS-Mac
This appears to be a duplicate of  Issue 714177 . 

From a security POV, this attack is out-of-scope because Chrome does not consider local attackers within its threat model.

Chrome does attempt to protect password fields on OS X (see Issue 695415) and https://cs.chromium.org/search/?q=EnableSecureEventInput+package:%5Echromium$&type=cs

Comment 2 by wfh@chromium.org, Oct 12 2017

Cc: rsesek@chromium.org shrike@chromium.org
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Security Pri-2 Type-Bug
Status: Untriaged (was: Unconfirmed)
This seems like a security feature request to me, and as comment #1 says, we do not consider this within our threat model to defend against these types of attackers.

However, if it's easy to switch our code to use NSSecureTextField and there are no reasons not to then perhaps we should, so punting it to the Mac triage queue.

Comment 3 by rsesek@chromium.org, Oct 12 2017

Mergedinto: 677220
Status: Duplicate (was: Untriaged)

Sign in to add a comment