Using IM-Visor to stop untrusted IME apps from stealing sensitive keystrokes

cybersecurity.springeropen.com

12 points·christianbryant··3 comments

I think the cool factor here is that they "propose a new idea, pre-IME, which guarantees that “Is this touch event a sensitive keystroke?” analysis will always access user touch events prior to the execution of any IME app code."

In the paper they note as "a pre-IME design, IM-Visor always recognizes and isolates sensitive keystrokes before the IMEs could access them. To achieve this, whenever a user intends to type in a soft keyboard, the STIE will be initialized to intercept touch events and analyze whether it is a sensitive keystroke."

This model is one that begs a matching and reversed exploration of "sensitive keystroke" emulation and whether such pre-IME analysis can be fooled.

I’m not sure this is a good solution, but maybe it’s the best “general” fix.

Basically an OS should be able to easily identify when you’re using a platform password field for instance and not interact with the IM (although that causes problems with assistive technologies). But the OS can’t really handle every third party reimplementation of password fields. Presumably a 3rd party solution would be able to rev faster and stay more up to date than the OS. (The risk balance when the OS is involved is higher than for just the IM as if it does break you can always remove the “visor”, but doing so in the os is harder.

Agreed. I do like the creative thinking here, though. And it makes one think about what an IM-Visor means for InfoSec outside this scenario; I'll be honest, I've not thought about it and I see all sorts of topics here worth exploration. For instance, what's to stop a malicious app to install and emulate the IM-Visor essentially intercept the data "acting" as the pre-IME defense stage?

Reply on news.ycombinator.com