Issue metadata
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 descriptionThis 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]
,
Oct 12 2017
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.
,
Oct 12 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Oct 11 2017Labels: OS-Mac