vmonaco / kloak

Keystroke-level online anonymization kernel: obfuscates typing behavior at the device level.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

kloak freezes any keyboard input

adrelanos opened this issue · comments

Happened to me in a Whonix 14 KDE workstation. (No longer available for download unfortunately.) Couldn't reproduce anywhere else. Apparently happens after boot when sdwdate reloads Whonix iptables firewalls rules. I don't know how to add any debug options to kloak.

Please kindly let me know how we can record kloak debug output so we can see where it chokes.

By freezes input, do you mean the keyboard becomes completely unresponsive? Did the exit combo (LShift+RShift+Esc) have any effect?

Starting with the -v options will print debug output. Is that what you're looking for?

Thanks, I'll try to reproduce.

Note that since verbose prints key codes, this will output sensitive information (e.g., passwords) in plain text. So make sure only to use -v when debugging and not in production.

kloak emergency keys not are easy to hit. I need a lot attempts until it works even without the bug happening yet. (Unrelated to this bug: kloak emergency key results in messing up the keyboard layout without ability to reset it using setxkbmap de. Pressing arrow up key results in A.

After the bug happened, I did not manage to press the emergency keys again.

Debug output enabled, but after the bug happened, no more output by kloak.

To crash kloak, run date. Copy its output.

date

Thu 11 Apr 2019 09:38:45 PM UTC

Then set the time (back to past, untested if setting to future would do as well)

sudo set --set "Thu 11 Apr 2019 09:38:45 PM UTC"

(In Whonix, sdwdate can clause clock jumps after boot. This is probably the trigger here.)

After triggering the bug it was like I was pressing enter all the time which I did not.

This was reproduced on Whonix VirtualBox 15.0.0.0.7.
(Whonix VirtualBox 15.0.0.0.7 - Debian buster based - Testers Wanted!)

Indeed this causes an issue. kloak assumes that system time is monotonically increasing, an oversight on my part. I'll add some error checking that handles this.

Now fixed. Was missing an upper bound on the interval used to generate random delays, got stuck in an infinite loop which explains why the keyboard froze (and emergency keys not detected).

Related: should the default emergency keys be changed? They can be specified through the -k parameter, but perhaps there's a more sensible default combo to use.