Open Bug 713314 Opened 13 years ago Updated 2 years ago

Add optional keylogger detection to input fields, especially password input fields.

Categories

(Core :: Layout: Form Controls, defect)

defect

Tracking

()

People

(Reporter: briansmith, Unassigned)

References

Details

(Keywords: china-p2)

+++ This bug was initially created as a clone of Bug #713312 +++

Some sites, in particular banking and e-commerce sites in China, are using ActiveX controls and/or NPAPI plugins that implement anti-keylogger techniques (of various levels of effectiveness). One of the anti-keylogger features is an ActiveX control that is basically a regular Win32 edit control that, AFAICT, checks for the the presence of keyloggers.

There are definitely limits to the detection and prevention of keyloggers. The main goal here is to satisfy the security requirements of various sites, especially sites in China, for keylogger protection. We should work with the sites to understand their requirements before getting too deep into this.

One of the things they do (AFAICT) is check for the presence of keyboard hooks [1][2][3]. I do not know if the control somehow disables the keyboard hooks for the input control (I suspect this is not possible), or whether it just disables the control and/or warns the user. We will have to test these plugins to see how they behave when keyboard hooks are installed on the system.

These edit controls may do other things to detect/prevent keylogging. We need to investigate this and get feedback from the sites using these controls.

I believe we have a contact at Alipay, which is one site that uses such a control. Mozilla China may be able to get useful technical information from them about what exactly their plugin does to prevent keylogging, to help us with our own implementation. Mozilla China might also be able to get such information from other sites, including Chinese Banks, that use such controls.

I am tempting to mark this Windows-only, because that is by far the most urgent platform to support this for, for the Chinese cases. Obviously it would be great to provide this support on all platforms; however, we shouldn't delay shipping the Windows implementation because of delays in implementing it for other platforms. I suggest we file other follow-up bugs for implementing it on other platforms after we've implemented it on Windows.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms644990%28v=vs.85%29.aspx
[2] http://msdn.microsoft.com/en-us/library/windows/desktop/ms644984%28v=vs.85%29.aspx
[3] http://msdn.microsoft.com/en-us/library/windows/desktop/ms644985%28v=vs.85%29.aspx
No longer depends on: 713312
How does this do more than address techniques *currently* used for keylogging?  That is, how does it prevent other keylogging techniques?  If a major browser shipped something like this, wouldn't people writing keyloggers just switch to a different technique?
(In reply to David Baron [:dbaron] from comment #1)
> How does this do more than address techniques *currently* used for
> keylogging?  That is, how does it prevent other keylogging techniques?  If a
> major browser shipped something like this, wouldn't people writing
> keyloggers just switch to a different technique?


We should get clarification (probably through Mozilla China) from the websites that use these plugins, as to why they feel like protection against certain types of keyloggers is warranted even though there are ways to create keyloggers that we could not detect.

I think the undetectable techniques may require admin rights (elevation) to install. So, maybe these websites are trying to block keylogging techniques that do NOT require elevation, and/or might only be possible on Windows XP, which doesn't have the UAC, UIPI, and other UI security stuff that modern Windows has. (In particular, it looks like the security properties of SetWindowHookEx have changed dramatically from Windows XP to Vista.)
sec triage, holding for more action
> We should get clarification (probably through Mozilla China) from the
> websites that use these plugins, as to why they feel like protection against
> certain types of keyloggers is warranted even though there are ways to
> create keyloggers that we could not detect.

I brought this up at the Security Engineering meeting today about the plugin at https://login.taobao.com/member/login.jhtml?f=top&redirectURL=http://www.taobao.com/index_global.php which has a name that is translated to mean that it is a security-related plugin.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.