regreSSHion:OpenSSH RCE

人在機場準備要回台灣,在 Hacker News 上看到「RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (qualys.com)」這個整個被抽醒,Qualys 的 security advisory 在這:「regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (CVE-2024-6387)」。

剛剛看 Ubuntu 套件已經更新了,請儘快更新...

OpenSSH 官方的「release-9.8」內有提到這是 race condition 造成的問題,在 32-bit 的 lab 環境上面大約六到八小時可以打進去,64-bit 環境理論上應該也是可行的,但時間還沒有被驗證:

Successful exploitation has been demonstrated on 32-bit Linux/glibc systems with ASLR. Under lab conditions, the attack requires on average 6-8 hours of continuous connections up to the maximum the server will accept. Exploitation on 64-bit systems is believed to be possible but has not been demonstrated at this time. It's likely that these attacks will be improved upon.

在 security advisory 裡面有提到更細節的部分,解釋了 race condition 的攻擊對象,以及為什麼 OpenBSD 沒中獎:

This vulnerability is exploitable remotely on glibc-based Linux systems, where syslog() itself calls async-signal-unsafe functions (for example, malloc() and free()): an unauthenticated remote code execution as root, because it affects sshd's privileged code, which is not sandboxed and runs with full privileges. We have not investigated any other libc or operating system; but OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.

這幾天應該會有更多測試出來,另外 Hacker News 上有人提到上個月 OpenSSH 打算內建阻擋系統的事情,有在猜測跟這個 security advisory 有關?(參考「OpenSSH 要內建阻擋系統了」)...

Anyway,後續可以再研究看看,但現在先趕緊把手上機器更新一輪比較要緊...

幫你打理伺服器環境的 piku

但文件寫的很糟:「The tiniest PaaS you've ever seen. Piku allows you to do git push deployments to your own servers.」。

名字來自於 Dokku,另外應該是用到了 pico 這個數量級詞:

piku, inspired by dokku, allows you do git push deployments to your own servers, no matter how small they are.

這個工具是在「Piku: Allows git push deployments to your own servers (github.com/piku)」這邊看到的,就如同說明提到的,希望透過 git push 就可以發佈軟體。

不過在討論裡面也有人抱怨文件的問題,像是在 id=40625339 這邊就有人提到。

實際到 AWS 上開了一台 EC2 instance 測,看起來就是提供一包 script 把伺服器端設定好,包括了 Let's Encrypt + nginx 以及 SSHGit 相關的設定,接著你可以直接將這台 server 設為 git remote,然後就可以用 git push 推軟體上去了。

對於只是想要跑軟體,而且容易接 CI/CD 的方案來說還算 OK,但如果想要自己客製化 nginx 或是一些工具的情境就不是那麼適用了。

穿越 Firewall 的作法

先看到「SSH over HTTPS (trofi.github.io)」這篇,原文「SSH over HTTPS」講怎麼利用 HTTPS 加上 CONNECT 指令穿過去。

作者有先介紹背景,他需要在醫院待個幾天,而醫院有免費的 WiFi 可以上網,但限制很多,基本上 TCP 的部分只有 80/tcp 與 443/tcp 會通,另外他有行動網路可以用 (但應該不是吃到飽的?),可以當作在現場直接設定 bypass 機制的工具:

I planned to spend 1-2 days in the hospital and did not plan to use the laptop.But now I am stuck here for the past two weeks and would like to tinker on small stuff remotely. The hospital has free Wi-fi access.

The caveat is that hospital blocks most connection types. It allows you only to do HTTP (TCP port 80) and HTTPS (TCP port 443) connections for most hosts. DNS (UDP port 53) and DoT (TCP port 853) seem to work as well at least for well-known DNS providers.

But SSH (TCP port 22 or most other custom ports) is blocked completely.

I wondered how hard would it be to pass SSH through HTTP or HTTPS. I had a GSM fallback so I could reconfigure remote server and try various solutions.

作者的方法就是在 TLS/SSL connection 上面跑 SSH,以前幹過,但就如同 comment 裡面提到的,Cisco 的 AnyConnect (主要是用 open-source client 的 OpenConnect 以及 open-source server 的 ocserv) 比較彈性,而且 AnyConnect 的協定會自動嘗試 UDP-based 的 DTLS,傳輸效率會比 TCP-based 的協定好,另外在 iOS 上可以直接裝 app store 裡面 Cisco 官方的 client 來用。

但從作者的其他文章看起來應該也是熟門熟路了,會這樣做應該是手上有 HTTPS 的 apache server 可以設定來用。

另外作者雖然沒寫出來,但想法應該是有 SSH 就可以在 command line 透過 -D 生出 SOCKS 服務當 proxy 讓其他程式使用,常見的應用程式大多都支援。

應該就是臨時要在醫院裡面待個一兩天時的暫時性方案,如果常態會遇到的話應該是會架 ocserv 來繞...

scp -3:直接對兩個 remote host 複製檔案

剛剛找資料才發現的,scp 指令早就可以針對兩個遠端複製檔案了:「scp from one remote server to another remote server」。

可以加上 -3,像是這樣:

scp -3 src:/foo/bar/a.zip dst:/tmp/

不過依照說明可以不用加,因為這是 default 值:

Copies between two remote hosts are transferred through the local host. Without this option the data is copied directly between the two remote hosts. Note that, when using the legacy SCP protocol (via the -O flag), this option selects batch mode for the second host as scp cannot ask for passwords or passphrases for both hosts. This mode is the default.

看了 Stack Exchange 上的回答日期,是 2014 年十月回的,所以至少 Ubuntu 16.04 就有這個功能了?(沒有去查這個功能多早...)

之前一直都是查怎麼用 rsync 搬,然後發現做不到所以都還是傻傻的透過 jump server 轉運檔案,沒想到隔壁棚早就給了解法...

這樣有些情境搬檔案就簡單多了...

OpenSSH 加入了 noise (keystroke timing obfuscation) 功能

Hacker News 上看到在 OpenSSH 裡加入 keystroke timing obfuscation 的功能:「Keystroke timing obfuscation added to ssh(1) (undeadly.org)」。

如同 commit log 裡面提到的,這個功能會想要故意沒事就送一些沒用的資料 (增加一些噪音),降低從 side channel 被判讀的資訊量:

This attempts to hide inter-keystroke timings by sending interactive traffic at fixed intervals (default: every 20ms) when there is only a small amount of data being sent. It also sends fake "chaff" keystrokes for a random interval after the last real keystroke. These are controlled by a new ssh_config ObscureKeystrokeTiming keyword/

基於 OpenSSH 算是 SSH 這塊的 de-factor standard 了,接下來看其他家像是 Dropbear 會不會也實作?

SSH 的各種好用的功能

在「An Excruciatingly Detailed Guide To SSH (But Only The Things I Actually Find Useful)」這篇看到在介紹 SSH 的各種好用的功能。

其中當然會提到 tunnel,這部份裡面提到了一張圖,原始文章是「A Visual Guide to SSH Tunnels: Local and Remote Port Forwarding」這邊,圖解 SSH tunnel 的功能 (不過只有 -L-R 的):

回到原來這篇文章,這篇講的東西比較多一點,關於 tunnel 相關的還包括了 -D-J

另外提到了 -A-t-g~? 的用法,以及其他各種跟 SSH 有關的工具。

翻了一輪後應該就 -g 還不熟,另外發現 -J (ProxyJump) 居然可以用逗號 , 指定一串跳板機,一路跳進去... 翻了 manpage 發現有寫:

Multiple jump hops may be specified separated by comma characters.

Tailscale SSH 可以啟動側錄功能

Tailscale 宣布 Tailscale SSH 可以側錄:「Announcing session recording for Tailscale SSH in beta」,這主要是對於 compliance 需求會有幫助,以前有類似需求的話會透過 jump server 類的方式來側錄...

這次提供的是 asciinema 格式,很容易可以 replay:

When a member of your tailnet initiates a connection over Tailscale SSH, our client on the server records all of the terminal output in asciinema format, and streams it to a dedicated recorder node on your tailnet.

開放給所有使用者,包括免費版本:

Session recording for Tailscale SSH is available in beta on our Free and Enterprise plans.

舊的 SSH session logging 則是宣布在八月會停掉:

This feature replaces a legacy version of local SSH session logging that saves recordings directly to the SSH server’s filesystem. We are deprecating that feature, and anyone using it should migrate to the new SSH session recording feature. The legacy functionality will remain active until at least August 1, 2023.

Hacker News 的討論「Session recording for Tailscale SSH in beta (tailscale.com)」裡面有一些有趣的東西,像是 sudo 也有提供類似的功能:「Sudoreplay」。

之前有遇過一些商用方案,有提供類似的功能,像是 CyberArk 的「Configure recordings and audits (PSM for SSH)」。

另外 2016 年時 AWS 的人也有寫過「How to Record SSH Sessions Established Through a Bastion Host」。

算是稽核上常見的需求,先前就有不少方法了,Tailscale 提供的工具等於是簡化了一些步驟。

OpenSSH 與 Dropbear 對 Ed25519 的支援

查了一下這兩個 server 端的軟體支援 Ed25519 的時間點。

OpenSSH 是在 2014/01/30 的 6.5 就支援了:

* ssh(1), sshd(8): Add support for Ed25519 as a public key type. Ed25519 is a elliptic curve signature scheme that offers better security than ECDSA and DSA and good performance. It may be used for both user and host keys.

算是相當久以前就支援了。對應到第一個支援的 Debian 版本是 Jessie 使用的 OpenSSH 6.7:「sshd(8) — openssh-server — Debian jessie — Debian Manpages」;第一個支援的 Ubuntu (LTS) 版本是 Trusty (14.04) 用的 OpenSSH 6.6:「openssh source package in Trusty」。

Dropbear 這邊就晚不少,在 2020/06/15 的 2020.79 版本才支援:

- Support ed25519 hostkeys and authorized_keys, many thanks to Vladislav Grishenko. This also replaces curve25519 with a TweetNaCl implementation that reduces code size.

所以對應到第一個支援的 Debian 版本是 Bullseye 的 2020.81:「Debian -- Details of package dropbear in bullseye」;第一個支援 Ubuntu (LTS) 的版本是 Jammy (22.04) 的 2020.81:「Ubuntu – Details of package dropbear in jammy」。

這樣看起來如果就是想要用 Ed25519 的話,變成 server 端的軟體得配合:預設裝的 sshd 應該都是 OpenSSH,如果想要換 Dropbear 的話要看 distribution 內給的版本夠不夠新,或是透過 PPA 之類的方法裝新版。

但大多數採用 BusyBox 的機器應該沒有採用新版 Dropbear (像是 AP 刷機),這邊還是得使用其他 key format,如果要避開 NIST 有介入的格式,就還是得用 ssh-rsa 了。

GitHub 更換 github.com 的 SSH host key (RSA 部份)

看到 GitHub 宣佈更換 SSH key (RSA 的部份):「We updated our RSA SSH host key」。

Hacker News 上的「We updated our RSA SSH host key (github.blog)」這邊有人提到官方文件 (原文裡面也有提到),裡面會列出對應的 key:「GitHub's SSH key fingerprints」。

只是看起來這些大公司依然對 DNSSEC + SSHFP 這樣的組合沒興趣...

OpenSSH 9.0 的 scp 與 sntrup761x25519 (Streamlined NTRU Prime)

OpenSSH 9.0 發行了,從 release-9.0 這邊可以看到重點,首先是 scp 的底層換掉,改用 SFTP 了,這點在先前「OpenSSH 的 scp 改用 SFTP 協定」這邊也有提到過:

This release switches scp(1) from using the legacy scp/rcp protocol to using the SFTP protocol by default.

另外一個是將 OpenSSH 8.9 引入的 post-quantum cipher 放入 default:

ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default ("sntrup761x25519-sha512@openssh.com"). The NTRU algorithm is believed to resist attacks enabled by future quantum computers and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo.

We are making this change now (i.e. ahead of cryptographically-relevant quantum computers) to prevent "capture now, decrypt later" attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available.

查了一下 Streamlined NTRU Prime 發現有 djb 參與,而且發現頭銜上面有掛中研院:

Daniel J. Bernstein, University of Illinois at Chicago, USA, and Ruhr University Bochum, Germany, and Academia Sinica, Taiwan

清單裡面有不少中研院的人:

Ming-Shing Chen, Academia Sinica, Taiwan

Bo-Yuan Peng, National Taiwan University and Academia Sinica, Taiwan

裡面還看到魯教授

Bo-Yin Yang, Academia Sinica, Taiwan

後面也有看到計畫相關的資訊:

Taiwanese authors were supported by Taiwan Ministry of Science and Technology Grants 108-2221-E-001-008 and 109-2221-E-001-009-MY3, Sinica Investigator Award AS-IA-109-M01, Executive Yuan Data Safety and Talent Cultivation Project (AS-KPQ-109-DSTCP).