In a series of commits starting here and ending with this one, Damien Miller completed the removal of all support for the now-historic SSHv1 protocol from OpenSSH.
在新的 distribution 裡引入新版 OpenSSH 時就不會有 SSHv1 的功能了...
在「Make Sure DSA Signing Exponentiations Really are Constant-Time」這篇文章裡面，直接透過 end-to-end 的 timing attack 打爆 (也就是透過 internet 觀察攻擊)，而不需要在同一台機器上對 cache 之類的區域攻擊：
A unique feature of our work is that we target common cryptographic protocols. Previous works that demonstrate cache-timing key-recovery attack only target the cryptographic primitives, ignoring potential cache noise from the protocol implementation. In contrast, we present end-to-end attacks on two common cryptographic protocols: SSH and TLS. We are, therefore, the first to demonstrate that cache-timing attacks are a threat not only when executing the cryptographic primitives but also in the presence of the cache activity of the whole protocol suite.
而且次數相當的少，就可以 key recovery：
260 SSH-2 handshakes to extract a 1024/160-bit DSA host key from an OpenSSH server, and 580 TLS 1.2 handshakes to extract a 2048/256-bit DSA key from an stunnel server.
Recently a Google engineer noticed that their SSH client segfaulted every time they tried to connect to a specific host. That engineer filed a ticket to investigate the behavior and after an intense investigation we discovered the issue lay in glibc and not in SSH as we were expecting.
由於等級到了 glibc 這種每台 Linux 都有裝的情況，在不經意的情況下發生 segfault，表示在刻意攻擊的情況下可能會很糟糕，所以 Google 投入了人力研究，想知道這個漏洞到底可以做到什麼程度：
Thanks to this engineer’s keen observation, we were able determine that the issue could result in remote code execution. We immediately began an in-depth analysis of the issue to determine whether it could be exploited, and possible fixes. We saw this as a challenge, and after some intense hacking sessions, we were able to craft a full working exploit!
In the course of our investigation, and to our surprise, we learned that the glibc maintainers had previously been alerted of the issue via their bug tracker in July, 2015. (bug). We couldn't immediately tell whether the bug fix was underway, so we worked hard to make sure we understood the issue and then reached out to the glibc maintainers. To our delight, Florian Weimer and Carlos O’Donell of Red Hat had also been studying the bug’s impact, albeit completely independently! Due to the sensitive nature of the issue, the investigation, patch creation, and regression tests performed primarily by Florian and Carlos had continued “off-bug.”
攻擊本身需要繞過反制機制 (像是 ASLR)，但仍然是可行的，Google 的人已經成功寫出 exploit code：
Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post.
技術細節在 Google 的文章裡也有提到，buffer 大小固定為 2048 bytes，但取得時有可能超過 2048 bytes，於是造成 buffer overflow：
glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query.
Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated.
另外 glibc 官方的 mailing list 上也有說明：「[PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflow」。
It was discovered that the OpenSSH client experimental support for resuming connections contained multiple security issues. A malicious server could use this issue to leak client memory to the server, including private client user keys.
這下除了要更新以外，要重新生 ssh key 然後更新一堆機器了...
公司有買 VMware license，但一直沒研究要如何做一份 VM template 出來，所以花了點時間研究到底怎麼做才會比較好。
這邊提供的方法是為了之後的通用性 (像是之後有可能用 KVM 堆虛擬機)，所以不使用 VMware 獨規的設計，因此有些設定需要手動調整。
首先是先生出一台 Ubuntu 14.04.1 的 VM，在裝完基本系統後有些要先處理的：
/etc/ssh/ssh_host_*，每台機器的 host key 應該要不一樣。
做好 VM 後轉成 Template，之後每次在 deploy 完、開起來後，還要做這些事情：
dpkg-reconfigure openssh-server重新產生 SSH host key。
make compiling against OpenSSL optional (make OPENSSL=no);
reduces algorithms to curve25519, aes-ctr, chacha, ed25519;
allows us to explore further options; with and ok djm
不過缺了 RSA 還是有點痛啊，看看會不會實做出來吧？
在 Slashdot 上看到 ChaCha20-Poly1305 將被移植到 OpenSSH 上：「OpenSSH Has a New Cipher — Chacha20-poly1305 — from D.J. Bernstein」。
ChaCha20-Poly1305 以 stream cipher 企圖同時解決這兩個問題，接下來就是看時間考驗了...