Bug: Out of bounds read in `ydotool type`

[AstroSnail]

When ydotool type is asked to type unicode characters, sometimes strange keypresses are generated.

For example, on my computer, asking ydotool to type "Å" causes it to press the Numpad 0/Insert key:

[erry@soon:~]$ ydotool type Å
^[[2~

This is because inside Client/tool_type.c, the loop that reads characters and transforms them into keycodes doesn't correctly handle non-ASCII characters. Specifically:

• This loop in tool_type (the same thing happens in the other loop) passes each byte read from the input almost unchanged and unchecked into type_char.

  • The check for escape sequences doesn't apply to unicode, and the cast from int to char causes bytes greater than 127 to become negative because char is signed on my system.

• type_char uses the char directly to index into an array that only contains values for the range of ASCII characters.

The result is that any time a byte greater than 127 is read, the array is indexed out of bounds.

On my system, "Å" is encoded in UTF-8 as the sequence 0xC3 0x85, which ydotool type uses to index the array out of bounds in two separate cases, and one of the out-of-bounds reads produces 0x73250052. As the function takes the lower 16 significant bits of the value as the keycode (and the most significant bit is unset, so it is not considered uppercase), this results in pressing keycode 0x0052 (decimal 82), which corresponds to Numpad 0 (if Num Lock is off, this is the same as Insert).

I'm disappointed that ydotool does not support typing unicode characters, but I'm ready to admit that, at this stage, supporting them will involve a lot of work. Therefore I think the easiest fix would be to add an extra check before calling type_char that ensures the byte is within the range of 0 to 127.