PuTTY 使用 ecdsa-sha2-nistp521 的漏洞

看到「PuTTY vulnerability vuln-p521-bias (greenend.org.uk)」這個消息,官網的說明在「PuTTY vulnerability vuln-p521-bias」這邊。

DSA 類的簽名演算法有個得很小心的地方,是 nonce 選擇不當會造成 key recovery,這在原文有提到:

All DSA signature schemes require a random value to be invented during signing, known as the 'nonce' (cryptography jargon for a value used only once), or sometimes by the letter k. It's well known that if an attacker can guess the value of k you used, or find any two signatures you generated with the same k, then they can immediately recover your private key.


With DSA, the entropy, secrecy, and uniqueness of the random signature value {\displaystyle k} are critical. It is so critical that violating any one of those three requirements can reveal the entire private key to an attacker. Using the same value twice (even while keeping {\displaystyle k} secret), using a predictable value, or leaking even a few bits of {\displaystyle k} in each of several signatures, is enough to reveal the private key {\displaystyle x}.

這次爆炸的起因是 PuTTY 用了 SHA-512 產生 nonce,這邊只會有 512 bits 的輸出,而這對 P-521 需要 521 bits 是不夠的 (於是前 9 個 bit 會是 0):

PuTTY's technique worked by making a SHA-512 hash, and then reducing it mod q, where q is the order of the group used in the DSA system. For integer DSA (for which PuTTY's technique was originally developed), q is about 160 bits; for elliptic-curve DSA (which came later) it has about the same number of bits as the curve modulus, so 256 or 384 or 521 bits for the NIST curves.

In all of those cases except P521, the bias introduced by reducing a 512-bit number mod q is negligible. But in the case of P521, where q has 521 bits (i.e. more than 512), reducing a 512-bit number mod q has no effect at all – you get a value of k whose top 9 bits are always zero.

而更糟的是,這不僅僅是將降了 29 的安全性,而是因為 nonce 有 bias,這在 DSA 上已經足以從 60 次的簽出的 signature 中還原出 private key (也就是文章裡提到的 key recovery attack):

This bias is sufficient to allow a key recovery attack. It's less immediate than if an attacker knows all of k, but it turns out that if k has a biased distribution in this way, it's possible to aggregate information from multiple signatures and recover the private key eventually. Apparently the number of signatures required is around 60.

新版會改用 RFC 6979 (Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)) 實作:

To fix this vulnerability, we've completely abandoned PuTTY's old system for generating k, and switched to the RFC 6979 technique, for all DSA and ECDSA key types. (EdDSA keys such as Ed25519 already used a different system, which has not changed.) However, this doesn't affect the fact that information about existing P521 private keys has already been leaked whenever a signature was generated using the old k generator.

所以這次的 fix 得更新 PuTTY 版本,然後重新產生 private key (會假設已經 leak 了),然後看看系統有什麼要處理的...

用 SessionGopher 拉出機器上各種密碼與 Key

同事在 Slack 上提到 fireeye/SessionGopher 這個工具,可以從機器上拉出各種敏感資訊:

SessionGopher is a PowerShell tool that uses WMI to extract saved session information for remote access tools such as WinSCP, PuTTY, SuperPuTTY, FileZilla, and Microsoft Remote Desktop. It can be run remotely or locally.

方法是掃 registry 或是硬碟:

SessionGopher works by querying the HKEY_USERS hive for all users who have logged onto a domain-joined box at some point. It extracts PuTTY, WinSCP, SuperPuTTY, FileZilla, and RDP saved session information. It automatically extracts and decrypts WinSCP, FileZilla, and SuperPuTTY saved passwords. When run in Thorough mode, it also searches all drives for PuTTY private key files (.ppk) and extracts all relevant private key information, including the key itself, as well as for Remote Desktop (.rdp) and RSA (.sdtid) files.

是個... 好玩... 的... 東西...

用 mRemoteNG 取代 PuTTY

由於架構的隔離政策,有些服務需要透過 VM 裡面的 Windows 存取,所以又花了點時間看看 PuTTY 到底有沒有改善下載問題,也就是 2014 年「Downloading Software Safely Is Nearly Impossible」這邊作者提到的問題 (之前在「如何安全下載軟體...」這篇有提過)。

而即時再過了兩年半,還是沒辦法確認你抓到的 PuTTY 是正確的,Let's Encrypt 還是沒上...

找了一些替代方案,看到 mRemoteNG 這個可以連多種不同 Protocol 的專案,應該會是解法,裝起來用了一陣子感覺還算 okay,之後應該會拿這個用:「mRemoteNG is the next generation of mRemote, open source, tabbed, multi-protocol, remote connections manager.」。

話說回來,找資料的時候發現「simon-git: putty-website (master): Owen Dunn」這篇,在三月提到了:

Switch to https for release binary downloads from the.earth.li

The main PuTTY website is still http until chiark sorts out
LetsEncrypt or other SSL arrangements, but I think we can sensibly
switch to https for the release binaries from the, which already
provides https.


PuTTY 安全性問題 (CVE-2015-5309)

雖然很久沒用 PuTTY 了 (因為用 Ubuntu 很久了),不過很難得看到 PuTTY 有安全性問題。

PuTTY 官方發佈了安全性通報 CVE-2015-5309:「PuTTY vulnerability vuln-ech-overflow」:

Versions of PuTTY and pterm between 0.54 and 0.65 inclusive have a potentially memory-corrupting integer overflow in the handling of the ECH (erase characters) control sequence in the terminal emulator.

不過老問題還是沒解啊,透過 HTTPS (i.e. Certificate authority 架構) 雖然有很多問題,但至少還是個靠稽核制度而建立的安全信任機制,在沒有任何可信任環境下可以當作起點下仍然是最好的方案:「如何安全下載軟體...」。



然後就看到一篇純粹抱怨文,以 PuTTY 為例,要肯定確定抓到的軟體是沒被「加料」過的卻是困難重重:「Downloading Software Safely Is Nearly Impossible」。

PuTTY 算是資訊安全類的軟體,但卻發現難以找到合理的方式確認 XDDD

首先是要先判斷「哪個站台是正確的官方站台」時,卻發現 putty.org 這個網域不是原作者 Simon Tatham 擁有,而即使是公認的官方網站 www.chiark.greenend.org.uk 的 greenend.org.uk 這個網域,也不是原作者擁有。

然後 www.chiark.greenend.org.uk 沒有提供 HTTPS,所以下載下來後還要想辦法確認沒被動手繳過。而作者的 RSA public key 放在 earth.li 網域上,同樣的這也不是作者擁有的網域,而且也遇到同樣問題:public key 的下載也不支援 HTTPS。

然後去 MIT 上的 PGP key server 翻也沒翻到,然後文章作者就崩潰自暴自棄直接執行下去了 XDDD

PuTTY 的這一串過程好像從以前就沒改善... XD

PuTTY 0.61

昨天看到 PuTTY 出 0.61 了:「PuTTY version 0.61 is released」,相隔四年多的另外一個新版。

看 New features 裡面,我看到一點還蠻有趣的:

On Windows: the Appearance panel now includes a checkbox to allow the selection of non-fixed-width fonts, which PuTTY will coerce into a fixed-width grid in its terminal emulation. In particular, this allows you to use GNU Unifont and Fixedsys Excelsior. (Thanks to Randall Munroe for a serious suggestion that inspired this.)

這代表可以用各種奇怪的字體嗎?主力系統換成 Ubuntu 後就沒用 PuTTY 了...