You skipped over the step actually writing an exploit for this.
This is some typical memory corruption. Exploiting these on any modern-day system isn't as straightforward as it was in the past. With ASLR and other mitigations you usually need some form of memory leak to find out about addresses. But even if you have that you need some way for your exploit to know about the leaked address. Most exploits that do this involve some form of scripting (the most common being browser-based exploits written in javascript).
I have no idea how you would pull that off in a README file.
- Someone dislikes JavaScript and uses Lynx in xterm for their browsing. Make a web page that such people are likely to want to view.
- Someone doesn’t like HTML email or tracking pixels, so they use Mutt in xterm. Put the crafted bytes in the subject of an email to them.
- Put it in the MOTD of an SSH server. For that matter, in the version string of your server so that someone running “ssh -v attacker.example.com” sees it.
This is so bad. Please go patch your systems immediately.
It's still extremely bad and should be patched immediately. But it doesn't appear to be a zero-interaction vulnerability, as far as I can tell from the description.
> To reproduce in XTerm, decode the file then try to select the line.
For the original report on screen, see https://lists.gnu.org/archive/html/screen-devel/2021-02/msg0... (warning, contains the raw test case, may crash a text-based browser).
Specifically, the overflow is in the upper limit of the text selection buffer when characters are combined in UTF-8.
SSHing into a host is probably sufficient and often crosses a "higher to lower" security boundary.
If someone runs my installer without checking the contents, why would I need UTF-8 bugs to get code executed?
(Not meant to downplay this bug, but the example made me wonder...)
> xterm through Patch #365 allows remote attackers to cause a denial of service (segmentation fault) or possibly have unspecified other impact via a crafted UTF-8 character sequence.
https://access.redhat.com/security/cve/CVE-2021-27135 has more information, explaining that “a specially crafted sequence of combining characters causes an out of bounds write leading to arbitrary code execution.”, and that:
> This vulnerability can be mitigated by disabling UTF-8 support in XTerm configuration. An entry such as "XTerm.vt100.utf8: false" in Xresources will disable UTF-8. This can be set as a system default in /etc/X11/Xresources, or per-user in ~/.Xresources. > > Note that this setting can still be overridden if xterm is invoked with the "-u8" command line option, so the mitigation may not protect all use cases.
Xterm doesn’t get a lot of reports, but a CVSS 9.6 is a doozy. An attack vector might look like:
- Upload a package to PyPI or Node.js that emits specially crafted console output as part of its installer.
- Profit.
From a previous HN story (https://news.ycombinator.com/item?id=11248847) UTF-8 support is enabled by default on OpenBSD, and probably all other distros by now.