> 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.

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...)

It includes examples that work for crashing, so if you're browsing HN on links for some reason, I wouldn't go reading it.

Before he thought of a UTF-8 encode taking 4x the space, now he assumes 6x. This not a fix! A fix is to provide the destlen, and realloc if off bounds. Probably in a loop.

There was a similar-seeming recent vulnerability in GNU screen.

You can see the problem on this very thread. Josh Triplett points out that (unlike the screen variant of the vulnerability), the xterm vulnerability requires user interaction: you have to select the text. And yet it has practically the maximum possible CVSS score. What does CVSS even mean if the difference between a zero-interaction drive-by RCE and one that requires an idiosyncratic user interaction is just 0.4 points?

This is a little like Clickjacking, where you'd expect a bounty hunter to come at you with "this very severe bug can be triggered simply by clicking", and you respond "well, we should fix that, but users never click in those places, so we're going to send you a t-shirt" and the bounty hunter responds "no, clicking is a fundamental user interaction, you should send me $5000".

And my point isn't even that this is a dumb bug (certainly, it's not as dumb as CJ usually is). It's that there is absolutely no fucking way it is a 9.6 on a 10.0 scale of severity. Shellshock, ffs, has the same NVD CVSS as this bug. Shellshock doesn't even care what terminal you're using.

Yeah, with all due respect, you're not in touch with what ordinary responses are.

When people see zalgo like the infamous SO regex post, selecting it is the first thing they do.

NVD gives Shellshock the same CVSS as this vulnerability, which requires a user in xterm to see a bunch of international UTF-8 characters and select them precisely enough to make a memory corruption exploit encoded in those characters run --- and do that without any feedback from the target, because what you're interacting with here is xterm, not a network service you can talk directly to, or a Javascript runtime.

I do not agree to disagree. The CVSS here is simply wrong.

CVSS is literally a Ouija board. I'm not just calling it that because it's unreliable or based on superstition. I'm saying that the process of arriving at a CVSS score is Ouija-like: you fill out a calculator or something, get a score that has no relation to your intuition of the severity of the vulnerability, and start applying small bits of pressure here and there to land on the score you know the vulnerability should land on. In fact: if you don't do that, you get exceptionally dumb CVSS scores for everything. It's a mess.

If you want to call out the severity of a vulnerability, you should do so with objective facts. "Remote code execution" is a good tip-off. "CVSS 9.6" is not.

But in the case where multiple vendors have scores like:

- Amazon: Important (https://alas.aws.amazon.com/AL2/ALAS-2021-1619.html)

- Ubuntu: 9.8 (https://ubuntu.com/security/CVE-2021-27135)

- Red Hat: 9.6 (https://access.redhat.com/security/cve/CVE-2021-27135)

…it starts to look like there’s consensus that not only is there an RCE, but it’s really easy to exploit. I think that’s where CVSS starts to come in handy. An RCE is bad, but one that’s trivial to actually use is extra bad. And yes, CVSS absolutely has some Ouija properties, but it’s the most commonly used metric I’ve seen for communicating how bad a vulnerability actually is. In this case, it wasn’t just the reporter who said it was bad but all the affected vendors agreeing with them.

I can't think of a better illustration of how bad CVSS is.

Once again: my point isn't that the vulnerability is unimportant (though: it's not nearly as important as it likely seems) or that it doesn't belong on the HN front page (it is a very, very funny vulnerability). It's simply that we should not be editorializing CVSS scores into titles, or taking CVSS scores seriously when they occur organically in titles.

CVSS is very, very bad. It is the CISSP of security metrics.

So that should be easy to tell whether your system has it fixed or not, beside the Fedora and Debian links in the article.

https://www.ubuntuupdates.org/package/core/groovy/universe/u...

I think gnome-terminal is based on vte, which wasn't affected.

I have no clue about Konsole.

sixels, this is a terminal graphics format. You could use them to have thumbnails in ls output, or view image attachments in mutt.

Tektronix mode, which is like a line-drawing mode - gnuplot supports it, so you can have really nice looking graphs and plots.

There are just little quality of life improvements, like being able to dump the screen in html format, preserving colors and attributes, or easy one-click access to the alternate screen buffer.

It's also easy to automate. You can use something like xtermcontrol to easily adjust anything from a script. Fonts, window size and position, etc. You can have custom key and mouse bindings too, and these are really powerful, but I'll concede the configuration format is arcane :-)

I'm sure I have xterm installed but I have never run it locally since like probably most people I just use the terminal emulator for my desktop environment.

Same for xterm. It's terrible and almost nobody uses it.

And they would need to be willing to spend a lot of time on making sure the new implementation was just the same as the old version, and can compile and run on all the same platforms and what not.

I don't think it would be easy to get funding for that, so your dedicated team is going to have to be independently wealthy, or not spend a lot of time on it.

If rust is your selected less unsafe language, as I understand it, it doesn't have as full platform support as gcc or clang, so that's a challenge (which gets easier over time as non-x86 and non-arm die out). Other languages have other challenges, but I don't think there's a clear winner here, which is part of the issue.

The new utilities will be judged on functionality (should be exactly the same), and cpu/memory/binary size which should all be the same or less. It's hard to guarantee that.

Not a whole lot of people want to develop with that framework. You don't see a whole lot of Show HN: I made a replica of X, with no changes to functionality. Everyone always wants to change things.

Anyway: be the change you want to see and all that. Pick a small package, reimplement it in rust (or whatever), and see if you can get it in distributions or convince the upstream to switch to your implementation. Then tell us how it went, and repeat with another package, etc.