misc/59051: edt-1.9's "keypad_configure" function performs global configuration of remote X session

[jon.brase%gmail.com@localhost]

>Number:         59051
>Category:       misc
>Synopsis:       edt-1.9's "keypad_configure" function performs global configuration of remote X session
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 07 11:30:01 +0000 2025
>Originator:     Jon Brase
>Release:        10.1
>Organization:
N/A
>Environment:
NetBSD <hostname redacted> 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/vax/compile/GENERIC vax
>Description:
The "edt" editor has a function that tries to determine what character sequences keys on the user's keypad produce. The first phase opens an X11 window (the editor does not seem to otherwise use X) and asks the user to type a sequence of keys into that window, then a phase is run that asks the user to type different keys into the terminal window. After both phases have run, edt asks if the user wishes to commit the keybindings determined from the probe to a file, which can then be passed in to future invocations of edt with the EDT_KEYPAD_SETUP environment variable.

My impression was that this process only probes what keycodes are produced and does not configure anything outside of edt itself, and that the configuration for edt that is produced only takes effect if the appropriate environment variable is set.

However, even if the process is aborted before edt saves the resulting configuration to disk, the phase that opens the X11 window appears to actually somehow affect global configuration on the X Server, and to do so over forwarded X sessions! (But I suppose the last bit is the price you pay for network transparency...).

Specifically, after running keypad_configure on a remote instance of edt, Num Lock no longer responds on my local machine, and numpad keys now generate responses for local X11 clients that are not consistent with their normal num-lock-on or num-lock-off functions.
>How-To-Repeat:
Remote machine setup:

Install NetBSD 10.01 Vax on simh (or other Vax emulator)

Configure sshd to forward X11

Install edt


Local machine setup:

Install x86_64 Kubuntu 22.04 on a VM (or use an existing install on real hardware, but be aware that successful reproduction of the issue will cause potentially annoying reconfiguration of the keymapping for your keypad).

Connect to the Vax system with ssh -X.

Run edt (preferably for the first time since installed).

Once the editor presents you with a prompt, run "keypad_configure", follow the instructions on screen.
>Fix:
No fix is known.

I'm not sure if the issue at hand counts as a "bug" in the original context edt was written in, but edt appears to make assumptions about the environment that it is running in that are not appropriate on modern platforms. Whether the functionality provided by "keypad_configure" is still relevant and/or whether it can be implemented in friendlier ways is to be considered.

Also, while given that behavior at hand provides a great object lesson on the security implications of X11 forwarding, it is probably best not to include functionality in an X client that is likely to produce surprises in that environment.

I have not yet attempted logging out and restarting X on the server end as I have ongoing work I'm attempting to finish. Depending on whether the configuration changes persist beyond the end of the X session, I may need assistance in determining what changes edt actually made so that they can be reverted.