Unauthenticated Remote Code Execution in Erlang/OTP SSH (opens in new tab)

Erlang, because of its architecture, has something of a habit of people rewriting various protocols in Erlang itself, rather than calling out to some C library.

This has pros and cons.

There's a huge difference here, historically that was because many C codebases were vulnerable due to inherent C flaws and ssh daemons due to their age was C based. OpenBSD folks stances on coding and system design avoids pitfalls.

This is an Erlang daemon, thus written in a managed language without buffer overflows,etc, but it seems like someone left a huge gaping logic hole to drive a bus through. SSH or not, this could've equally well been a logic hole in a base webserver,etc.

I'd say this is more akin to the Log4j debacle, a perfectly safe language but bad design makes it vulnerable to something trivial.

OpenSSH has actually been "pwned" numerous times though. It's a very desirable target.

I also have this principle, although I make an exception for https://tinyssh.org

I was too! The reason is that the Go x/crypto/ssh library was bailing out on the lack of reply to the channel open request, which prevented it from reaching the auth bypass check via exec. I should have an update out soon with this fixed and a RCE check for this issue.

The test server: $ erl -eval 'ssh:start(), ssh_dbg:on(), ssh:daemon(34222, [{system_dir, "/home/otp/ssh/keys"},{user_dir, "/home/otp/ssh/users/otptest/.ssh"}]).'

The exploit: auth.ScrapeExec(options, addr+" "+tname, res, ses, `os:cmd("touch /tmp/HAXXXED").`)

>-rw-r--r-- 1 root root 0 Apr 17 16:14 /tmp/HAXXXED

Design bug here: Clearly we need to run code as somebody, so, there's no reason to have infrastructure which just executes user code with the current context or server (presumably? or maybe an actual zero, ie root) context.

If we design the software this way, when we try to write the erroneous code we're caught - oh, wait, which user is authenticated? We need to... oh... we shouldn't be here without authenticating.

> It makes for a fun demo, but a regular OS shell is more useful, and you can attach a debug shell to an existing BEAM process from there.

OTOH for example in Go people sometimes use the SSH protocol to provide access to cool things like an SSH based chat, instead of using it for shell access.

I haven’t looked at what the Erlang SSH server provides, but maybe you could do something like that? Write a chat server in Erlang and use the Erlang SSH server to provide users access to that chat?

> overall the Erlang/Elixir ecosystem is very strong and lacks most of the footguns like an "eval" statement that get people

Erlang has erl_eval [1] if you're looking for more ability to shoot yourself in the foot. You can call that from Elixir, but I guess that'd be weird; I'm not an Elixir person, but I'd bet you can shoot yourself in the foot if you try!

There's always fun with dist and proc_lib:spawn(Node, Fun) [2], which you can put in a list comprehension with erlang:nodes() [3] if you want to shot yourself in many feet rapidly ;)

[1] https://www.erlang.org/doc/apps/stdlib/erl_eval.html

[2] https://www.erlang.org/doc/apps/stdlib/proc_lib.html#spawn/2

[3] https://www.erlang.org/doc/apps/erts/erlang.html#nodes/0

There absolutely is an eval function in the Elixir standard library:

https://hexdocs.pm/elixir/1.18.3/Code.html#eval_string/3

I’ve seen more horrendous code using macros in elixir even despite by brief foray than I have seen ever in decades of working in languages with eval. Like using them when normal functions would suffice.

> most obvious way to run a shell command [1]

I think you forgot a link to your [1] reference.

Just create your own.