5 ms·

Xterm code execution via font ops

65 points by jwilk 4y ago

jwilk 4y ago
I tried to put "<375" in the submission title, but HN would truncate the title just before "<".
taviso 4y ago
I think the mitigation advice is incomplete, allowFontOps is disabled by default, so the mitigation is only necessary if you've enabled it.. but in that case you would need to put 'allowFontOps: false' after the stanza enabling it, right?
- jwilk 4y ago
  > allowFontOps is disabled by default It's enabled by default upstream. https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:allowFontOps https://invisible-island.net/xterm/manpage/xterm.html#VT100-...
  - taviso 4y ago
    That's what the manual on fedora says too, but it is disabled by default. I admit, I didn't try building from pristine source, so it could be patched!
    - jwilk 4y ago
      It looks patched indeed: https://src.fedoraproject.org/rpms/xterm/blob/rawhide/f/xterm-defaults.patch https://src.fedoraproject.org/rpms/xterm/blob/rawhide/f/xter...
      - taviso 4y ago
        Ah-ha, I stand corrected :)
        dgl 4y ago
        Debian's patch is nicer, as the build process pulls the default from the man page, so: https://sources.debian.org/patches/xterm/375-1/904_fontops.diff/ https://sources.debian.org/patches/xterm/375-1/904_fontops.d...
        jwilk 4y ago
        > the build process pulls the default from the man page Interesting idea, but I don't think that's what happens: https://sources.debian.org/src/xterm/375-1/debian/rules/#L22 https://sources.debian.org/src/xterm/375-1/debian/rules/#L22
tyingq 4y ago
Does make me wonder how many people are left that use xterm regularly. I still use it, solely because of muscle memory from when it was one of few options. But it seems like most unixy operating systems offer up something else as the default terminal. And xterm being xterm, it's a bit of work to get it running nicely with a decent font and cut/paste behavior. So you have to be pretty deliberate about wanting it.
- badsectoracula 4y ago
  I use xterm as my only terminal since it has pretty much zero dependencies, opens instantly, it is very responsive, supports everything (it is kind of a defacto standard) and the UI is minimal (just a scrollbar).
  - taviso 4y ago
    I use it too, nothing is quite so configurable, feature rich or reliable. I'll admit that XtTranslations are not user friendly, but they are powerful!
  - jmclnx 4y ago
    I will do a me-too also. I find xterm works great with tmux plus I can easily change font size on the fly without any issues. Change font sizes on other terminals is either not allowed or sometime (rarely) corrupts the display.
  - p_l 4y ago
    There's a menubar and context menu, but one needs to know how to enable them in the first place ;)
- UI_at_80x24 4y ago
  I use it for cross-site compatibility primarily. I connect to hundreds of various *nix servers. Various Linux, FreeBSD, OpenBSD, and AIX. I don't notice font differences much (I'm half blind, so everything is rather large on my screen (and all fonts are kinda fuzzy)). But what I do notice is that xterm is the only program that shows things like ncurses (i.e. mc, tree, etc.), and tmux, and language/locale correctly on everything. I can get 1-2 of the above items but never all of them. (Konsole does a great job too, but xterm opens faster on my i3 setup.) I've manipulated my various dotfiles, and tried multiple combinations but xterm works 100% of the time.
vngzs 4y ago
-- $XTermId: README,v 1.3 2007/05/24 19:49:19 tom Exp $ -- Below is the original README for xterm from 1991, for your amusement. -- For a better overview, see http://invisible-island.net/xterm/ Abandon All Hope, Ye Who Enter Here This is undoubtedly the most ugly program in the distribution. It was one of the first "serious" programs ported, and still has a lot of historical baggage. Ideally, there would be a general tty widget and then vt102 and tek4014 subwidgets so that they could be used in other programs. We are trying to clean things up as we go, but there is still a lot of work to do. If you are porting this to a machine that has problems with overlapping bcopy's, watch out! There are two documents on xterm: the man page, xterm.man, which describes how to use it, and ctlseqs.ms, which describes the control sequences it understands.
- nonrandomstring 4y ago
  There are so many modern, compact, versatile Xterm compatible terminal emulators that can be aliased. Is there any serious reason in 2022 to still be distributing instead of dragging it out behind the woodshed with a shovel.
  - somat 4y ago
    There is a quote. Around computers it is difficult to find the correct unit of time to measure progress. Some cathedrals took a century to complete. Can you imagine the grandeur and scope of a program that would take as long? -- Epigrams in Programming, ACM SIGPLAN Sept. 1982 Well, we have our cathedrals in programing, only we as as software engineers tend to be barbarians and call them "legacy code" or "obsolete systems" or "needs to be torn down and replaced with something new". Think of when people do this to actual cathedrals. I like xterm, use it daily, I think Thomas Dickey is a pretty great guy for his role in maintaining the program. https://www.invisible-island.net/xterm/xterm.html https://www.invisible-island.net/xterm/xterm.html
    - nonrandomstring 4y ago
      Now I feel deservably bad. Xterm is is also part of my daily go-tos. But then I look through apt or yum and see so many fresh faced usurpers, many written in modern languages... and also hear the same laments that Xterm is "unmaintainable". I didn't think of it as someone's cathedral. I'll put the shovel down. ;)
anarcat 4y ago
as mentioned in the fine article, it looks like many distros patched this out already, for some reason. Debian has that default flipped since Debian squeeze, published in 2011: https://sources.debian.org/src/xterm/261-1/debian/changelog/#L242 https://sources.debian.org/src/xterm/261-1/debian/changelog/... so yeah, kind of a big deal, except not really, looks like some folks were already careful with that possibly dangerous setting. :)
guenthert 4y ago
"This does mean to exploit this vulnerability the user needs to be using Zsh in vi line editing mode (usually via $EDITOR having "vi" in it). While somewhat obscure this is not a totally unknown configuration." I think by now, both users have adjusted their settings.
- iudqnolq 4y ago
  If this happens automatically if EDITOR contains the substring "vi" then I'd guess this effects a significant portion of the xterm user base. I don't think it does, though. This is based only on my rough memory that I used to use nvim and zsh and didn't notice that.
  - dgl 4y ago
    [Original finder here; I wrote that, I checked.] See the docs: https://github.com/zsh-users/zsh/blob/f8d93888a8efd6c8142e74ece83b38632661de47/Doc/intro.ms#L1271-L1273 https://github.com/zsh-users/zsh/blob/f8d93888a8efd6c8142e74... Relevant code: https://github.com/zsh-users/zsh/blob/f8d93888a8efd6c8142e74ece83b38632661de47/Src/Zle/zle_keymap.c#L1457-L1459 https://github.com/zsh-users/zsh/blob/f8d93888a8efd6c8142e74...
classichasclass 4y ago
Serious question: is xterm really entirely at fault here? Doesn't zsh get some of the blame? > It so happens ^G is in Zsh when in vi line editing mode bound to "list-expand". Which can run commands as part of the expansion leading to command execution without pressing enter!
- Beltalowda 4y ago
  I don't see why; it just has a keybind for Control+G.
- ilyt 4y ago
  Other example of "running stuff when you just use the shell without pressing enter" is say listing a git branches when you use completion so no. The exploit is "sending something that looks like user input that can also contain ^G"
- bawolff 4y ago
  I blame xterm. Control sequences should not trigger key presses. That's a recipe for disaster. I think its entirely reasonable for a terminal program to bind any key it wants to execute a command.
- kazinator 4y ago
  What if xterm the text "rm -rf .\n" in response to some character sequence; could we blame the shell, or rm?
- skissane 4y ago
  xterm is (arguably) implementing ECMA-48 wrong: replies to out-of-band strings (such as OSCs) should themselves be marked as out-of-band (by embedding them in an OSC/APC/DCS/PM, terminated with ST not BEL). Instead it is replying to an out-of-band command in-band. However, I think the design of the Unix tty subsystem is also at fault here - out-of-band messages (OSC/APC/DCS/PM) should be filtered out by default and only delivered to processes which explicitly declare that they are expecting them. That said, if zsh is putting the tty in raw mode, it is saying it wants everything the terminal will send it, so it needs to do that filtering itself.
midislack 4y ago
zsh considered harmful, not for the first time. This is why I use pdksh.
- somat 4y ago
  For those of us who like the openbsd ksh(all two of us) which is derived from pdksh. there is the project oksh. https://github.com/ibara/oksh https://github.com/ibara/oksh I don't know if this is helpful or just annoying unsolicited "advice"

65 points by jwilk 4y ago

I tried to put "<375" in the submission title, but HN would truncate the title just before "<".

I think the mitigation advice is incomplete, allowFontOps is disabled by default, so the mitigation is only necessary if you've enabled it.. but in that case you would need to put 'allowFontOps: false' after the stanza enabling it, right?

jwilk 4y ago
> allowFontOps is disabled by default It's enabled by default upstream. https://invisible-island.net/xterm/manpage/xterm.html#VT100-Widget-Resources:allowFontOps https://invisible-island.net/xterm/manpage/xterm.html#VT100-...
- taviso 4y ago
  That's what the manual on fedora says too, but it is disabled by default. I admit, I didn't try building from pristine source, so it could be patched!
  - jwilk 4y ago
    It looks patched indeed: https://src.fedoraproject.org/rpms/xterm/blob/rawhide/f/xterm-defaults.patch https://src.fedoraproject.org/rpms/xterm/blob/rawhide/f/xter...
    - taviso 4y ago
      Ah-ha, I stand corrected :)
      - dgl 4y ago
        Debian's patch is nicer, as the build process pulls the default from the man page, so: https://sources.debian.org/patches/xterm/375-1/904_fontops.diff/ https://sources.debian.org/patches/xterm/375-1/904_fontops.d...
        jwilk 4y ago
        > the build process pulls the default from the man page Interesting idea, but I don't think that's what happens: https://sources.debian.org/src/xterm/375-1/debian/rules/#L22 https://sources.debian.org/src/xterm/375-1/debian/rules/#L22

tyingq 4y ago

Does make me wonder how many people are left that use xterm regularly. I still use it, solely because of muscle memory from when it was one of few options. But it seems like most unixy operating systems offer up something else as the default terminal. And xterm being xterm, it's a bit of work to get it running nicely with a decent font and cut/paste behavior. So you have to be pretty deliberate about wanting it.

badsectoracula 4y ago
I use xterm as my only terminal since it has pretty much zero dependencies, opens instantly, it is very responsive, supports everything (it is kind of a defacto standard) and the UI is minimal (just a scrollbar).
- taviso 4y ago
  I use it too, nothing is quite so configurable, feature rich or reliable. I'll admit that XtTranslations are not user friendly, but they are powerful!
- jmclnx 4y ago
  I will do a me-too also. I find xterm works great with tmux plus I can easily change font size on the fly without any issues. Change font sizes on other terminals is either not allowed or sometime (rarely) corrupts the display.
- p_l 4y ago
  There's a menubar and context menu, but one needs to know how to enable them in the first place ;)
UI_at_80x24 4y ago
I use it for cross-site compatibility primarily. I connect to hundreds of various *nix servers. Various Linux, FreeBSD, OpenBSD, and AIX. I don't notice font differences much (I'm half blind, so everything is rather large on my screen (and all fonts are kinda fuzzy)). But what I do notice is that xterm is the only program that shows things like ncurses (i.e. mc, tree, etc.), and tmux, and language/locale correctly on everything. I can get 1-2 of the above items but never all of them. (Konsole does a great job too, but xterm opens faster on my i3 setup.) I've manipulated my various dotfiles, and tried multiple combinations but xterm works 100% of the time.

vngzs 4y ago

-- $XTermId: README,v 1.3 2007/05/24 19:49:19 tom Exp $ -- Below is the original README for xterm from 1991, for your amusement. -- For a better overview, see http://invisible-island.net/xterm/ Abandon All Hope, Ye Who Enter Here This is undoubtedly the most ugly program in the distribution. It was one of the first "serious" programs ported, and still has a lot of historical baggage. Ideally, there would be a general tty widget and then vt102 and tek4014 subwidgets so that they could be used in other programs. We are trying to clean things up as we go, but there is still a lot of work to do. If you are porting this to a machine that has problems with overlapping bcopy's, watch out! There are two documents on xterm: the man page, xterm.man, which describes how to use it, and ctlseqs.ms, which describes the control sequences it understands.

nonrandomstring 4y ago
There are so many modern, compact, versatile Xterm compatible terminal emulators that can be aliased. Is there any serious reason in 2022 to still be distributing instead of dragging it out behind the woodshed with a shovel.
- somat 4y ago
  There is a quote. Around computers it is difficult to find the correct unit of time to measure progress. Some cathedrals took a century to complete. Can you imagine the grandeur and scope of a program that would take as long? -- Epigrams in Programming, ACM SIGPLAN Sept. 1982 Well, we have our cathedrals in programing, only we as as software engineers tend to be barbarians and call them "legacy code" or "obsolete systems" or "needs to be torn down and replaced with something new". Think of when people do this to actual cathedrals. I like xterm, use it daily, I think Thomas Dickey is a pretty great guy for his role in maintaining the program. https://www.invisible-island.net/xterm/xterm.html https://www.invisible-island.net/xterm/xterm.html
  - nonrandomstring 4y ago
    Now I feel deservably bad. Xterm is is also part of my daily go-tos. But then I look through apt or yum and see so many fresh faced usurpers, many written in modern languages... and also hear the same laments that Xterm is "unmaintainable". I didn't think of it as someone's cathedral. I'll put the shovel down. ;)

anarcat 4y ago

as mentioned in the fine article, it looks like many distros patched this out already, for some reason. Debian has that default flipped since Debian squeeze, published in 2011: https://sources.debian.org/src/xterm/261-1/debian/changelog/#L242 https://sources.debian.org/src/xterm/261-1/debian/changelog/... so yeah, kind of a big deal, except not really, looks like some folks were already careful with that possibly dangerous setting. :)

guenthert 4y ago

"This does mean to exploit this vulnerability the user needs to be using Zsh in vi line editing mode (usually via $EDITOR having "vi" in it). While somewhat obscure this is not a totally unknown configuration." I think by now, both users have adjusted their settings.

iudqnolq 4y ago
If this happens automatically if EDITOR contains the substring "vi" then I'd guess this effects a significant portion of the xterm user base. I don't think it does, though. This is based only on my rough memory that I used to use nvim and zsh and didn't notice that.
- dgl 4y ago
  [Original finder here; I wrote that, I checked.] See the docs: https://github.com/zsh-users/zsh/blob/f8d93888a8efd6c8142e74ece83b38632661de47/Doc/intro.ms#L1271-L1273 https://github.com/zsh-users/zsh/blob/f8d93888a8efd6c8142e74... Relevant code: https://github.com/zsh-users/zsh/blob/f8d93888a8efd6c8142e74ece83b38632661de47/Src/Zle/zle_keymap.c#L1457-L1459 https://github.com/zsh-users/zsh/blob/f8d93888a8efd6c8142e74...

classichasclass 4y ago

Serious question: is xterm really entirely at fault here? Doesn't zsh get some of the blame? > It so happens ^G is in Zsh when in vi line editing mode bound to "list-expand". Which can run commands as part of the expansion leading to command execution without pressing enter!

Beltalowda 4y ago
I don't see why; it just has a keybind for Control+G.
ilyt 4y ago
Other example of "running stuff when you just use the shell without pressing enter" is say listing a git branches when you use completion so no. The exploit is "sending something that looks like user input that can also contain ^G"
bawolff 4y ago
I blame xterm. Control sequences should not trigger key presses. That's a recipe for disaster. I think its entirely reasonable for a terminal program to bind any key it wants to execute a command.
kazinator 4y ago
What if xterm the text "rm -rf .\n" in response to some character sequence; could we blame the shell, or rm?
skissane 4y ago
xterm is (arguably) implementing ECMA-48 wrong: replies to out-of-band strings (such as OSCs) should themselves be marked as out-of-band (by embedding them in an OSC/APC/DCS/PM, terminated with ST not BEL). Instead it is replying to an out-of-band command in-band. However, I think the design of the Unix tty subsystem is also at fault here - out-of-band messages (OSC/APC/DCS/PM) should be filtered out by default and only delivered to processes which explicitly declare that they are expecting them. That said, if zsh is putting the tty in raw mode, it is saying it wants everything the terminal will send it, so it needs to do that filtering itself.

midislack 4y ago

zsh considered harmful, not for the first time. This is why I use pdksh.

somat 4y ago
For those of us who like the openbsd ksh(all two of us) which is derived from pdksh. there is the project oksh. https://github.com/ibara/oksh https://github.com/ibara/oksh I don't know if this is helpful or just annoying unsolicited "advice"