CVE-2021-27135: xterm flaw may allow remote code execution, CVSS 9.6

https://nvd.nist.gov/vuln/detail/CVE-2021-27135

by kstrauser • 5 years ago

43 61 5 years ago

nvd.nist.gov

kstrauser9• 5 years ago

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.

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

formerly_proven• 5 years ago

An attack vector might look like

SSHing into a host is probably sufficient and often crosses a "higher to lower" security boundary.

kstrauser9• 5 years ago

Very true. There are a million ways to get text displayed on someone’s terminal.

syzzer• 5 years ago

Upload a package to PyPI or Node.js that emits specially crafted console output as part of its installer.

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

pengaru• 5 years ago

The host running the installer is often not the same as the one running the terminal emulator. Guess which is more likely to have keys to kingdoms?

kstrauser9• 5 years ago

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.

kstrauser9• 5 years ago

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.

JoshTriplett2• 5 years ago

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.

hannob• 5 years ago

An attack vector might look like:

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.

nynx3• 5 years ago

When is this madness of using unsafe languages for applications that interact with outside systems going to end?

tdhz77• 5 years ago

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.

burundi_coffee• 5 years ago

I think it still makes a difference if languages are created with safety in mind.

nynx3• 5 years ago

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.

geofft• 5 years ago

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.

Ar-Curunir• 5 years ago

All languages are unsafe the same way all diseases are fatal.

pjmlp• 5 years ago

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

toast03• 5 years ago

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.

tptacek9• 5 years ago

How about we just start with xterm and go from there?

ris• 5 years ago

We're patiently awaiting your rust-rewrite of xterm. When can we expect the first release?

gautamcgoel• 5 years ago

Has this been patched yet?

acidburnNSA• 5 years ago

Patch for Ubuntu was released on Feb 24.

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

rincebrain2• 5 years ago

There's a patch available, yes. Debian and Fedora at least are shipping it.

readflaggedcomm• 5 years ago

I believe it's the issue fixed in patch #366 reported by Ormandy, who is in the article's mailing list links: https://invisible-island.net/xterm/xterm.log.html

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

teddyh• 5 years ago

Yes: https://security-tracker.debian.org/tracker/CVE-2021-27135

tptacek9• 5 years ago

I don't think we need CVSS scores in titles. CVSS is a Ouija board metric.

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

kstrauser9• 5 years ago

I’d usually agree, but 9.6 indicates this is something you probably want to patch sooner rather than later.

tptacek9• 5 years ago

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?

rincebrain2• 5 years ago

Related discussion from when this crash was originally found in screen and then they found a slightly modified version also worked on xterm (I can't find any nontrivial discussion of it on HN, surprisingly, but I had this article's link in my browser history from a month ago because of it): https://lists.gnu.org/archive/html/screen-devel/2021-02/msg0... (and then https://www.openwall.com/lists/oss-security/2021/02/09/7 )

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

kyberias• 5 years ago

Am I safe if I use my Digital VT100 from the 80s?

mnd9992• 5 years ago

Depends - does it supports UTF-8?

toast03• 5 years ago

A fixed function terminal from the 80s certainly doesn't support a variable byte character encoding from the 90s.

egberts• 5 years ago

Yes. UTF-8 was not a thing during VT-100’s lifetime.

cozzyd4• 5 years ago

Not to downplay this bug, but how many people use xterm instead of gnome-terminal or Konsole? Or are those somehow affected too?

igetspam• 5 years ago

Lots. Xterm is everywhere. It's like using vim or emacs or bash. It's pretty much always there and always behaves the same.

sneak• 5 years ago

Yes, but despite vim being there on tons of systems, nobody except vim users ever run it.

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

cozzyd4• 5 years ago

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.

taviso2• 5 years ago

I dunno, I use xterm. It's fast, feature-rich, and every minute detail is configurable.

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

I have no clue about Konsole.

cozzyd4• 5 years ago

What are some features xterm has that I'm missing out by using gnome-terminal? Not doubting, just ignorant.

rurban• 5 years ago

The patch is still handwaving, and not doing proper boundschecks. https://github.com/ThomasDickey/xterm-snapshots/commit/82ba5...

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.

CVE-2021-27135: xterm flaw may allow remote code execution, CVSS 9.6

Related Stories