A security issue in xterm has been announced on November 10: https://www.openwall.com/lists/oss-security/2022/11/10/1 The issue is fixed upstream in 375: https://invisible-island.net/xterm/xterm.log.html or maybe it isn't: https://www.openwall.com/lists/oss-security/2022/11/10/5 but there's a PoC in the original message that can be used to check.
We already have v375 in Cauldron (thanks to ghibo). The original bug was: > xterm before patch 375 can enable an RCE under certain conditions. > Fix: Upgrade to xterm patch #375 > . > Mitigation: Set this Xresource: > XTerm*allowFontOps: false The second link above says: "Running xterm 375 on Arch Linux (Font Ops are enabled by default) and OpenBSD (after re-enabling Font Ops) shows it as still vulnerable using the test below.. [then a detailed explanation, particularly about *zsh*, ending with...] > to exploit this vulnerability the user needs to be > using Zsh in vi line editing mode (usually via $EDITOR having "vi" in > it). > In that configuration, something like: > printf "\e]50;i\$(touch /tmp/hack-like-its-1999)\a\e]50;?\a" > cve-2022-45063 > cat cve-2022-45063 # or another way to deliver this to the victim > Will touch that file. It will leave the line on the user's screen; Then whether the the mitigation or update is effective: > Debian, Red Hat and others disable font ops by default (see some > good foresight at[1] or this very list[2]), but users can re-enable them > via a configuration option or menu. Additionally upstream xterm does > not disable them by default, so some distributions include a > vulnerable default configuration. It looks here as if the user has to specifically configure (if disabled) the zsh vulnerability; so cannot complain. The new xterm version is probably worth having anyway; but we should watch our default configuration as per the Mitigation. Assigning to Giussepe having done recent updates to xterm.
Assignee: bugsquad => ghibomgx
Fedora has issued an advisory for this on November 20: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/IVD3I2ZFXGOY6BA2FNS7WPFMPFBDHFWC/
Severity: normal => major
I uploaded version 376 into mga8's updates_testing. [there was also a version in nonfree/updates_testing, but that's was a typo and should be ignored].
I fixed the release tag. xterm-376-1.mga8 from xterm-376-1.mga8.src.rpm
Assignee: ghibomgx => qa-bugsCC: (none) => ghibomgx
MGA8-64 MATE on Acer Aspire 5253 No installation issues. tested commands like ls pwd, opened vlc and filezilla, all OK. One strange thing, which might be specific for this MATE desktop and the lack of speed of the laptop. The NFS-shares are not mounted automatically in MATE here, havn't got to the bottom of this, but anyway mount -av solves the problem when I need the access. But when I give that command in xterm, the command executes OK, but then when I "ls" the mount, it returns nothing just as the mount was not done. But in the MATE terminal everything shows up. Back to the still open xterm: nothing. I had to close down the xterm, open it again and then I could display the contents of the NFS-mount. I will not object the OK of this update, but I want someone else's judgment on the subject.
Whiteboard: (none) => MGA8-64-OKCC: (none) => herman.viaene
I've run into something similar when using Dolphin to access my Android phone. If I'm not quick enough telling the phone it's OK to allow access, Dolphin times out and throws an error. I have to close Dolphin to clear the error and re-open it so it will access the phone. Seems to be the way it's designed. A security "feature," perhaps. I'm going to validate this. Herman, if you believe this warrants it, please feel free to open another bug about the nfs shares situation.
CC: (none) => andrewsfarm, sysadmin-bugsKeywords: (none) => validated_update
I've asked the sysadmins to remove the nonfree version. I tried the poc with the prior xterm , but failed to make it work. Not sure why, Ran printf "\e]50;i\$(touch /tmp/hack-like-its-1999)\a\e]50;?\a" > cve-2022-45063 $ cat .Xdefaults XTerm*allowFontOps: true Logged out/in to make the .Xdefaults take effect. In xterm ran "cat cve-2022-45063". The file /tmp/hack-like-its-1999 is created. Installed the update, deleted the tmp file, and redid the test. The tmp file is not created. Testers, when there is a poc please try to test with it before/after, to make sure the update actually fixes the issue. In this case it appears it does. At least it does for Mageia, even if it's not working on bsd systems. Advisory committed to svn.
CC: (none) => davidwhodginsKeywords: (none) => advisory
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2022-0441.html
Status: NEW => RESOLVEDResolution: (none) => FIXED