it's confirmed that version 184 is vulnerable, but for the other versions...? -------------------------- Description: David Remahl reported a vulnerability in xterm in the processing of window titles. A remote user may be able to cause arbitrary commands to be executed. The software does not properly validate user-supplied input. A remote user can provide content that includes specially crafted escape sequences that may cause arbitrary commands to be executed on the target user's system. The original advisory is available at: http://remahl.se/david/vuln/012/ Impact: A remote user may be able to cause arbitrary commands to be executed.
According to xterm's maintainer, this is a case of an insecure default configuration on Mac OS X. // David Remahl
X11 please check.
Seemant handles this.
Seemant please advise.
Regarding comment #1, something got lost in translation. The feature is configurable, and is normally enabled, irregardless of platform. (I've pointed this out in a few other places, but so far no packager has chosen to disable it).
Thomas -- what do we have to do to fix this stuff in Gentoo?
Add "*allowWindowOps:false" to the system's copy of XTerm in the app-defaults directory. The same for UXTerm of course.
ok, xterm-200-r2 and xterm-202-r1 are both in portage now. please make sure, arches, to mark *XTERM-200-R2* stable and NOT 202. The 202 is a development/unstable branch only (and realistically should be package.masked). Actually, I will do that. Once I get Thomas the output from 202 that causes breakages and we're able to sort it out, we can start looking at 202's unmasking. With that long-winded thing, I'm done now :)
Arches, please test and mark xterm-200-r2 stable Target KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 sparc x86"
sparc done. Builds and runs fine.
PPC stable.
stable on alpha ia64
Stable on ppc64.
Stable on hppa.
Ready for GLSA vote. I tend to vote 1/2 NO, as (if I understand correctly) it needs heavy user interaction to work... But maybe I didn't really understand it.
Well yes - it's mostly relying on a contrived example: user cat's a binary file to his terminal which just happens to be specially designed to send a "bad" shell command to be on the title-string of his terminal and then uses the retrieve-title feature to send the shell command back to the host - minus the trailing newline (because that doesn't come with the retrieve-title). User then is persuaded (?) to just press enter, completing the "bad" command.
definitely NO to glsa, imho.
another no from me as well I guess
Closing without GLSA
(In reply to comment #9) > ok, xterm-200-r2 and xterm-202-r1 are both in portage now. please make sure, > arches, to mark *XTERM-200-R2* stable and NOT 202. The 202 is a > development/unstable branch only (and realistically should be package.masked). > Actually, I will do that. Once I get Thomas the output from 202 that causes > breakages and we're able to sort it out, we can start looking at 202's unmasking. > > With that long-winded thing, I'm done now :) I'm guessing that echo "*allowWindowOps: false" > ${D}/etc/X11/app-defaults/XTerm echo "*allowWindowOps: false" > ${D}/etc/X11/app-defaults/UXTerm was supposed to be echo "*allowWindowOps: false" >> ${D}/etc/X11/app-defaults/XTerm echo "*allowWindowOps: false" >> ${D}/etc/X11/app-defaults/UXTerm
Sure, that's bug 95858
Stable on mips.
Thomas, is this still required for xterm #248? I'm asking because the issue is quite old, and I'd like to drop the hack from the ebuild if it's not required anymore.
The source still uses a true as default. I added menu entries and symbols (DEF_ALLOW_WINDOW in this case) which can be #define'd in a build as an alternative to patching the resource file.
Whether to make the resource default to false depends on the packager's preferences. For the record, I just checked Debian/testing using vttest, and see that except for konsole and mlterm, the terminal emulators I've got allow part or all of this group of escape sequences (and unlike xterm, that is not configurable ;-). The others: gnome-terminal, mrxvt, pterm, rxvt, rxvt-unicode
