Mailing-List: contact commits-help@guacamole.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@guacamole.incubator.apache.org
Date: Mon, 17 Jul 2017 09:28:00 +0000 (UTC)
From: "Sebastian Ohmsen (JIRA)" <jira@apache.org>
To: commits@guacamole.incubator.apache.org
Message-ID: <JIRA.13087524.1500283395000.260860.1500283680264@Atlassian.JIRA>
In-Reply-To: <JIRA.13087524.1500283395000@Atlassian.JIRA>
References: <JIRA.13087524.1500283395000@Atlassian.JIRA> <JIRA.13087524.1500283395114@jira-lw-us.apache.org>
Subject: [jira] [Updated] (GUACAMOLE-349) Currupt user input for guacamole
 sessions over RDP
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Mon, 17 Jul 2017 09:28:05 -0000


     [ https://issues.apache.org/jira/browse/GUACAMOLE-349?page=3Dcom.atlas=
sian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebastian Ohmsen updated GUACAMOLE-349:
---------------------------------------
    Description:=20
We've come across a bug that is corrupting the user input for guacamole ses=
sions over rdp. The problem only occurs when you open a RDP session inside =
the RDP session established by guacamole. Our use case is that we connect t=
o a Hyper-V server and would open the console of a VM running on it. You ca=
n very well test that too with connecting to any RDP server from the connec=
tion established by guacamole.

We've tested this extensively and we can observe the following: Whenever yo=
u press a key combination that produces another result by adding a modifier=
 key, like "SHIFT_R + ."(dot) which should lead to an ">" sign, it's only a=
 matter of time when this is mapped to a "."(dot) sign. This does not only =
occur when you hold both keys down, it also occurs occasionally when you pr=
ess it the first time. This makes entering passwords super hard and seems t=
o be a bug.

We've traced it down to the corresponding C code and think the problem is h=
ere:

https://github.com/apache/incubator-guacamole-server/blob/master/src/protoc=
ols/rdp/keyboard.c#L261

In some cases of extra mapped keys, for example in the above case, it's sen=
ding more keys than expected. We can see that =E2=80=9CSHIFT_L + .=E2=80=9D=
 results in following keysym updates:
=20
* 0xFFE1 (SHIFT_R) pressed
* 0x003E (>) pressed
* 0x003E (>) released
* 0xFFE1 (SHIFT_R) released

and works perfectly fine. In contrast =E2=80=9CSHIFT_R + .=E2=80=9D results=
 in following events:

* 0xFFE2 (SHIFT_R) pressed
* 0xFFE1 (SHIFT_L) pressed
* 0x003E (>) pressed
* 0xFFE1 (SHIFT_L) released
* 0xFFE1 (SHIFT_L) pressed
* 0x003E (>) released
* 0xFFE1 (SHIFT_L) released
* 0xFFE2 (SHIFT_R) released

which leads to the described behavior above.


  was:
We've come across a bug that is corrupting the user input for guacamole ses=
sions over rdp. The problem only occurs when you open a RDP session inside =
the RDP session established by guacamole. Our use case is that we connect t=
o a Hyper-V server and would open the console of a VM running on it. You ca=
n very well test that too with connecting to any RDP server from the connec=
tion established by guacamole.

We've tested this extensively and we can observe the following: Whenever yo=
u press a key combination that produces another result by adding a modifier=
 key, like "SHIFT_R + ."(dot) which should lead to an ">" sign, it's only a=
 matter of time when this is mapped to a "."(dot) sign. This does not only =
occur when you hold both keys down, it also occurs occasionally when you pr=
ess it the first time. This makes entering passwords super hard and seems t=
o be a bug.

We've traced it down to the corresponding C code and think the problem is h=
ere:

https://github.com/apache/incubator-guacamole-server/blob/master/src/protoc=
ols/rdp/keyboard.c#L261

In some cases of extra mapped keys, for example in the above case, it's sen=
ding more keys than expected. We can see that =E2=80=9CSHIFT_L + .=E2=80=9D=
 results in following keysym updates:
=20
* FFE1 (SHIFT_R) pressed
* 003E (>) pressed
* 003E (>) released
* FFE1 (SHIFT_R) released

and works perfectly fine. In contrast =E2=80=9CSHIFT_R + .=E2=80=9D results=
 in following events:

* FFE2 (SHIFT_R) pressed
* FFE1 (SHIFT_L) pressed
* 003E (>) pressed
* FFE1 (SHIFT_L) released
* FFE1 (SHIFT_L) pressed
* 003E (>) released
* FFE1 (SHIFT_L) released
* FFE2 (SHIFT_R) released

which leads to the described behavior above.


> Currupt user input for guacamole sessions over RDP
> --------------------------------------------------
>
>                 Key: GUACAMOLE-349
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-349
>             Project: Guacamole
>          Issue Type: Bug
>          Components: guacamole, RDP
>            Reporter: Sebastian Ohmsen
>
> We've come across a bug that is corrupting the user input for guacamole s=
essions over rdp. The problem only occurs when you open a RDP session insid=
e the RDP session established by guacamole. Our use case is that we connect=
 to a Hyper-V server and would open the console of a VM running on it. You =
can very well test that too with connecting to any RDP server from the conn=
ection established by guacamole.
> We've tested this extensively and we can observe the following: Whenever =
you press a key combination that produces another result by adding a modifi=
er key, like "SHIFT_R + ."(dot) which should lead to an ">" sign, it's only=
 a matter of time when this is mapped to a "."(dot) sign. This does not onl=
y occur when you hold both keys down, it also occurs occasionally when you =
press it the first time. This makes entering passwords super hard and seems=
 to be a bug.
> We've traced it down to the corresponding C code and think the problem is=
 here:
> https://github.com/apache/incubator-guacamole-server/blob/master/src/prot=
ocols/rdp/keyboard.c#L261
> In some cases of extra mapped keys, for example in the above case, it's s=
ending more keys than expected. We can see that =E2=80=9CSHIFT_L + .=E2=80=
=9D results in following keysym updates:
> =20
> * 0xFFE1 (SHIFT_R) pressed
> * 0x003E (>) pressed
> * 0x003E (>) released
> * 0xFFE1 (SHIFT_R) released
> and works perfectly fine. In contrast =E2=80=9CSHIFT_R + .=E2=80=9D resul=
ts in following events:
> * 0xFFE2 (SHIFT_R) pressed
> * 0xFFE1 (SHIFT_L) pressed
> * 0x003E (>) pressed
> * 0xFFE1 (SHIFT_L) released
> * 0xFFE1 (SHIFT_L) pressed
> * 0x003E (>) released
> * 0xFFE1 (SHIFT_L) released
> * 0xFFE2 (SHIFT_R) released
> which leads to the described behavior above.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)