←back to thread

Unauthenticated Remote Code Execution in Erlang/OTP SSH

(nvd.nist.gov)
199 points kimi | 2 comments | 17 Apr 25 13:29 UTC | HN request time: 0.432s | source
Show context
formerly_proven ◴[17 Apr 25 15:31 UTC] No.43718329[source]▶
If I interpret the patch correctly the issue seems to be that you could just ask for a channel and do a request_exec before authenticating. The regression test is:

    {send, hello},
    {send, ssh_msg_kexinit},
    {match, #ssh_msg_kexinit{_='_'}, receive_msg},
    {send, SshMsgChannelOpen},
    {send, SshMsgChannelRequest},
    {match, disconnect(), receive_msg}
https://github.com/erlang/otp/commit/6eef04130afc8b0ccb63c9a...

edit: Ah, found by the people at RUB, they do a lot of research in verifying protocol implementations iirc.

replies(4): >>43718365 #>>43718897 #>>43719016 #>>43720515 #
phoe-krk ◴[17 Apr 25 15:33 UTC] No.43718365[source]▶
CWE-306, Missing Authentication for Critical Function, linked in the report seems to suggest the same. The score of 10.0 is damn spicy, too - you just ask the server to execute something for you, and it does so, no questions asked.
replies(1): >>43718665 #
1. tialaramex ◴[17 Apr 25 15:54 UTC] No.43718665[source]▶
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.

replies(1): >>43719013 #
2. toast0 ◴[17 Apr 25 16:21 UTC] No.43719013[source]▶
Afaik, if you were running the Erlang SSH daemon, when you connect as an authorized user (or just ask!), it drops you into the Erlang debug shell. There's no concept of different users in the debug shell. Erlang dist is kind of an almost single system image cluster, with no security boundaries once you're connected to the cluster. (Well, not exactly no boundaries, you can mark a process sensitive, and ets tables private, and do some other things to make introspection difficult [1], but you can likely still spawn an os process debugger and get to everything; you would need to modify the OTP sources to disable os process spawning)

I didn't think anybody would actually run the Erlang SSH daemon, but there's evidence that some do. It makes more sense to run openssh, so you can debug BEAM failures etc, and you can load a debug shell from your OS shell easily.

[1] https://security.erlef.org/secure_coding_and_deployment_hard...