On Monday 24 February 2003 08:09 pm, Michael Jennings wrote: > > which were confirmed vulnerable include xterm, dtterm, uxterm, rxvt, > > aterm, Eterm, hanterm, and putty[1]. The tested applications that > > did not allow the title to be written include gnome-terminal 2.0, > > konsole, SecureCRT, and aterm. > > Just for clarification, you might want to specify whether or not aterm > was vulnerable since you listed it twice. (I'm guessing it wasn't.) Just when you think you've got all the typos ironed out... Yeah, aterm does not support the window title reporting feature. > Other than disabling the reporting of the title altogether, I see no > way of "sanitizing" this, as you put it, without blocking potentially > legitimate uses. So for now I've disabled the sequence you've noted, > along with the other one you didn't mention, until such time as > someone points out what I'm missing. Would stripping escape sequences from the window title work? Do you know of any applications that actually use this feature? > > Eterm should be given an award for the "Easiest to Compromise" > > terminal emulator. > > Ouch... > > Based on 0.9.1, I can see where you'd make that statement. I don't > believe that statement is true, however, with respect to 0.9.2. Absolutely correct, this paper was written over a period of months, the 0.9.1 release was the latest version available with most distributions when I made that claim. The reasons for picking on Eterm: * arbitrary command execution at one point in its lifetime * arbitrary file creation with user-defined content (via clear screen) * shared feature-sets with xterm, rxvt, etc * great documentation for all of these features ;) > I'm not sure what "vendor coordination" was done, but I know I was > never contacted. Just FYI. The vendor coordination was done through the vendor-sec mailing list with about a three-week head start prior to disclosure. There really weren't many true "bugs" found, just about everything covered was implemented deliberately and could be found in the documentation of the app. There had already been a number of debates on the exploitability of these features, so this paper was more of a FAQ than any sort of advisory. It wasn't my intention to catch anyone off-guard on this, just to bring these issues back into the limelight for a while and see if other people had a similar take on them. > But I find the alternative approach of lacking functionality for fear > of screwing something up to be a cop-out. :) -HD
This archive was generated by hypermail 2b30 : Tue Feb 25 2003 - 09:00:48 PST