Sorry for the title, but the linked page’s own title wasn’t very descriptive. The short version of the problem is:
> 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.
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.
Other attack vectors, for the purpose of illustrating that this is very important to patch:
- 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 not quite as bad as that; it sounds like you also have to select the text. (The corresponding vulnerability in "screen", by contrast, doesn't require interaction, which makes it even more serious.)
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.
Fair, so let’s skip the installation step and put the poison characters in its README so that `npm show hackerpackage` does the trick. Now installation isn’t necessary.
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.
No, it doesn't. That's exactly the problem. You can make CVSS say whatever you want it to.
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?
You have to select exactly the right text, and that text will never look like "select this right now" --- if you've seen the characters we're talking about, it's like Zalgo text. Selection in an xterm is not the ordinary response to these strings.
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.
That's what the bug bounty person says about their CJ bug. Meanwhile: NVD has given this the same score as Shellshock, which is dispositive of how bad CVSS is.
Shellshock was a universal RCE in anything that ran bash with control over environment variables --- which included a huge subset of all web services, often on any code path in which bash was just incidentally run. Not only that, but the vulnerability was exploited in bash; it wasn't memory corruption, there were no system-specific offsets to limit the scope of exploits, nor could you have preemptively hardened a system against it with ASLR or W^X.
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.
Once again: my point is that it is the opposite, because you can make lots of vulnerabilities read out this way even if they're not at all urgent --- and the opposite thing is true, very severe vulnerabilities can also get surprisingly low scores.
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.
I understand what you’re saying and generally agree. We get incoming bug bounty reports like “drop everything, here’s a 9.8 you need to fix right now!” that turns out be a misunderstanding.
But in the case where multiple vendors have scores like:
…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.
Ubuntu is just taking the score from NVD. Redhat has applied the first Ouija input to it, adjusting it to "user interaction required". That changed the score from a 9.8 --- 0.2 points from the maximum possible CVSS score --- all the way down to... 9.6.
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.
Off the top of my head, two features I don't think gnome-terminal can do:
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 :-)
Sure, and so is Xeyes and ed, but that doesn't mean many people use it. I might use xterm on a remote system I vnc into that has no desktop manager but other than that I'm generally running everything in my local terminal emulator (and then often also in tmux).
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.
You would need a dedicated team (starting with a dedicated person), willing to rewrite so much existing C code in a less unsafe language.
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.
All languages are unsafe. We find bugs of “safe” languages sometimes 30 years after the exploit was introduced. Just because we don’t know doesn’t make them safe.
Indeed, however given that 70% of exploits are caused by memory corruption bugs, like in this case, the IT world would be much safer if we only had to deal with the remaing 30%.
While that's true, the likelihood of a bug like this existing in an application written in a language like python, go, or rust (heck, even C++) is orders of magnitude less than the likelihood of it being in software written in C.
Why does Python have a safe reputation around here? Everything is constantly rewritten by corporate sponsored developers and it is usually easy to find invalid accesses.
It certainly does help but as the parent says it’s not a silver bullet.
The lazy unhelpful comment above adds very little to the discussion when the software in question is (in some cases decades) older than those languages.
Sometimes kids get badly injured climbing on a tiny playground structure, but we don't say "All climbing is unsafe" and stick toddlers halfway up El Capitan.
> 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.