ESC ] 6;12;? ESC \ freezes xterm with 100% CPU usage

[ais523]

Running the following command:

printf "\x1b]6;12;?\x1b\\"

while inside an xterm window causes xterm to stop responding to user input, produce no output, and consume 100% CPU usage (i.e. it runs indefinitely on a single core). Most likely this is a consequence of an infinite loop.

The bug is triggered by the character sequence produced by the above printf command being sent to the terminal via any means (e.g. placing it in a text file, and then using cat to display the text file, also causes xterm to enter an infinite loop).

The character sequence that printf outputs when running this command has a similar form to that of many xterm terminal commands, so most likely xterm is attempting to interpret it a command. That said, I don't think it's actually meaningful (it starts an OSC 6 command but then gives it invalid parameters). Nonetheless, xterm probably shouldn't go into an infinite loop as a response to a program printing text on it, no matter how meaningless that text is. (I stumbled across this particular sequence by chance when writing a terminal testsuite.)

I'm not sure whether this is a security-related bug or not, but it's certainly plausible that it could be used as a remote denial of service, or possibly to make it harder to view text files (as attempting to display them in xterm will cause it to crash). People don't normally expect running cat to be able to crash their terminal. As such, I'm classifying it as security-related as a precaution. Feel free to override this setting if you disagree.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: xterm 322-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-41.61-generic 4.4.21
Uname: Linux 4.4.0-41-generic x86_64
.tmp.unity_support_test.0:

ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CompizPlugins: [core,composite,opengl,decor,regex,snap,compiztoolbox,move,place,grid,gnomecompat,neg,obs,session,vpswitch,mousepoll,imgpng,resize,animation,expo,ezoom,workarounds,wall,fade,unitymtgrabhandles,scale,unityshell]
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Sat Oct 1 18:11:36 2016
DistUpgraded: 2016-05-02 01:10:52,869 ERROR got error from PostInstallScript ./xorg_fix_proprietary.py (g-exec-error-quark: Failed to execute child process "./xorg_fix_proprietary.py" (No such file or directory) (8))
DistroCodename: xenial
DistroVariant: ubuntu
DpkgLog:

ExecutablePath: /usr/bin/xterm
GraphicsCard:
 Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Hewlett-Packard Company 3rd Gen Core processor Graphics Controller [103c:2186]
InstallationDate: Installed on 2014-06-03 (851 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
MachineType: Hewlett-Packard HP Pavilion 15 Notebook PC
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-41-generic.efi.signed root=UUID=e92d655d-cf36-4d45-90e7-30a0f9d0949e ro quiet splash vt.handoff=7
SourcePackage: xterm
UpgradeStatus: Upgraded to xenial on 2016-05-02 (152 days ago)
dmi.bios.date: 09/21/2015
dmi.bios.vendor: Insyde
dmi.bios.version: F.68
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: 2186
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 35.12
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnInsyde:bvrF.68:bd09/21/2015:svnHewlett-Packard:pnHPPavilion15NotebookPC:pvr098B110000404100000620180:rvnHewlett-Packard:rn2186:rvr35.12:cvnHewlett-Packard:ct10:cvrChassisVersion:
dmi.product.name: HP Pavilion 15 Notebook PC
dmi.product.version: 098B110000404100000620180
dmi.sys.vendor: Hewlett-Packard
version.compiz: compiz 1:0.9.12.2+16.04.20160823-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.67-1ubuntu0.16.04.2
version.libgl1-mesa-dri: libgl1-mesa-dri 11.2.0-1ubuntu2.2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 11.2.0-1ubuntu2.2
version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20160325-1ubuntu1.1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.12-1build2
xserver.bootTime: Sat Oct 1 07:28:56 2016
xserver.configfile: default
xserver.errors:

xserver.logfile: /var/log/Xorg.0.log
xserver.outputs:
 product id 927
 vendor LGD
xserver.version: 2:1.18.4-0ubuntu0.1

[Marc Deslauriers (mdeslaur)]

Thanks for reporting this issue. Could you please report it to the xterm developer, see the following link:

http://invisible-island.net/xterm/xterm.faq.html#report_bugs

Also, can I make this bug public?

[ais523 (ais523)]

I've now reported the bug upstream, and asked the upstream whether they consider that the information needs to remain private until a fix. My main worry is that people will send the byte sequence in question to IRC channels or similar places particularly likely to echo all text received into a terminal, or inject the byte sequence in question into a log file, thus making the terminal unusable and pegging a CPU core of the system. If you feel those consequences are sufficiently small that the risk of making the bug report public is worth it, then I have no objection to making the bug public. Otherwise, it's likely best to wait to hear what upstream has to say.

[Marc Deslauriers (mdeslaur)]

Thanks! Please update this bug when you hear back from upstream.

[ais523 (ais523)]

On Thu, 2016-10-06 at a19:51 -0400, Thomas Dickey wrote:
> On Thu, Oct 06, 2016 at 01:28:05PM +0100, ais523 wrote:
> > I'm using xterm (version "XTerm(322)") on Ubuntu 16.04.1. If a
> > program sends the following byte sequence to the terminal:
[snip]
> thanks (I'll fix that - xterm's not detecting a error)

[snip]
> > I reported this bug to Canonical, and they asked me to file it
> > upstream. They're also interested in whether you consider the bug
> > to be security-related (which would require it to be kept secret), or
> > whether it's OK for the bug to be publicly known.
> any bug is a nuisance (this one won't sniff out your private
> information, so it's a matter of taste how to categorize it).

[ais523 (ais523)]

Thomas Dickey wrote:
> I added that to my ongoing fixes (I have another bug-report, expecting
> to get through that in the next day or so).

[Leonidas S. Barbosa (leosilvab)]

Hi, any update from upstream? Any link we can follow?
Thanks!

[ais523 (ais523)]

I haven't heard anything from upstream beyond what I've already posted in this bug report.

The bug still reproduces on Ubuntu Zesty. It does, however, seem to have been fixed upstream (I just downloaded the latest upstream tarball from http://invisible-island.net/xterm/#download and can't reproduce the bug on it, and the bug is also marked as fixed in the changelog). xterm doesn't seem to have a repository, so cherry-picking the fix for the specific security issue might not be easily possible.

[Leonidas S. Barbosa (leosilvab)]

Could you please point me the changelog entry and the bug number?

[ais523 (ais523)]

The changelog entry is here: http://invisible-island.net/xterm/xterm.log.html#xterm_327

I'm not sure there is a bug number. xterm doesn't seem to use a bug tracker.

[Leonidas S. Barbosa (leosilvab)]

Thanks Alex for taking time on this. I'm changing bug to security public so we can get more attention even it's already fix in upstream, given the difficulties to get the exact commit/patch to fix it.

[Thomas Dickey (dickey-his)]

That was xterm-326d, which if someone had asked politely, I've have pointed
to https://github.com/ThomasDickey/xterm-snapshots

[Leonidas S. Barbosa (leosilvab)]

Sorry Thomas, it was not my intention at all I'm new in xterm pkgs.
Thanks for point us this link.

[ais523 (ais523)]

This is now fixed in Ubuntu Bionic. Version information:

$ xterm -version
XTerm(330)
$ dpkg -s xterm | grep ^Version
Version: 330-1ubuntu2

This seems consistent with the statement that it was fixed in version 326d.