Bug 123521 - CAN-2003-0070 gnome terminal still vulnerable to command line insertion?
CAN-2003-0070 gnome terminal still vulnerable to command line insertion?
Product: Fedora
Classification: Fedora
Component: vte (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Brian Brock
: Security
: 103804 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-05-18 20:11 EDT by David Downes
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-18 15:50:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Downes 2004-05-18 20:11:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040312

Description of problem:
After typing 'cat' in a Gnome terminal, with one of the usb devices as
argument, an 'xterm' string appears.  This would seem to be unsafe
default behaviour, if it is intentional.  Have tried it on several
different usb devices and the result is the same e.g.

[dd@localhost dd]$  cat /proc/bus/usb/001/001
       @         �[dd@localhost dd]$ xterm
[dd@localhost dd]$  cat /proc/bus/usb/002/001
      @         ��[dd@localhost dd]$ xterm
[dd@localhost dd]$

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.open terminal window
2.type 'cat /proc/bus/usb/001/001'
3.press return

Actual Results:  [dd@localhost dd]$ cat /proc/bus/usb/001/001
       @         �xterm[dd@localhost dd]$ xterm
[dd@localhost dd]$

new xterm appears on desk top

Expected Results:  xterm should not be appearing when arbitrarily
using cat on files in proc

Additional info:
Comment 1 Thomas E. Dickey 2004-05-22 11:37:30 EDT
That sounds like the answerback string.  But I changed that to
an empty string 4 years ago (perhaps Redhat's customization of
app-defaults added it back).
Comment 2 Mark J. Cox (Product Security) 2004-05-26 06:45:28 EDT
There was a whole raft of security updates to various terminal
emulators, see CAN-2003-0063 for a reference.

This issue might still affect gnome-terminal, needs testing.  However
note that you still need to convince someone to press return in order
to execute the command.
Comment 3 Mark J. Cox (Product Security) 2004-05-26 06:48:07 EDT
see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0070
Comment 4 Ray Strode [halfline] 2004-06-17 18:20:17 EDT
*** Bug 103804 has been marked as a duplicate of this bug. ***
Comment 8 Ray Strode [halfline] 2004-06-18 15:50:52 EDT
Hi David.  vte (the component which gnome-terminal is built on)
interprets some unprintable "control" characters specially to provide
features for programs to be able to set the window title, move the
cursor around, switching the font to symbols (for drawing), and things
of that nature.  

Most recognized sequences of unprintable characters only cause some
visual change, but there are a few that will cause strings to be
injected directly onto the console.  In particular, with versions of
vte 0.11.10 and older the character ENQ (control-E) displayed "xterm".

When you cat binary data, the terminal can misinterpret parts of that
data as control characters.  This is why xterm is popping up.  Note,
newer versions of vte (and xterm) don't return "xterm", but instead
return an empty string when reading the ENQ character.  

For more information see the upstream bug reports:


Before version 0.10.25, vte would allow the window title to be sent to
the console, which had security issues.  Newer versions of vte will
not do this, however.

Note You need to log in before you can comment on or make changes to this bug.