CVE-2015-0235:讓人爆炸的「glibc gethostbyname buffer overflow」

CVE-2015-0235:glibc gethostbyname buffer overflow 的問題是:

Heap-based buffer overflow in the __nss_hostname_digits_dots function in glibc 2.2, and other 2.x versions before 2.18, allows context-dependent attackers to execute arbitrary code via vectors related to the (1) gethostbyname or (2) gethostbyname2 function, aka "GHOST."

這個洞讓只要有接受外部 hostname 查詢的部份就會中獎 (因為所有程式語言大概都是用這組 function 查詢,除了少部份是使用 DNS 查),再加上幾乎每支程式都會用到 glibc,在更新完後得重開機,於是有一堆機器得重開機更新了...

Ubuntu 12.04 中獎,不過 14.04 混過去了...

Apple 首次自動強制更新:NTP 安全問題

Apple 第一次的自動強制更新就給了這次的 ntpd 安全性問題 CVE-2014-9295:「Apple pushes first ever automated security update to Mac users」。

A remote unauthenticated attacker may craft special packets that trigger buffer overflows in the ntpd functions crypto_recv() (when using autokey authentication), ctl_putdata(), and configure(). The resulting buffer overflows may be exploited to allow arbitrary malicious code to be executed with the privilege of the ntpd process.

這次的問題比較刺激...

Git 安全性更新

GitHub 發了一篇公告說明這件事情:「Vulnerability announced: update your Git clients」,而 Git 官方的公告在這邊:「[ANNOUNCE] Git v2.2.1 (and updates to older maintenance tracks)」。

這次的問題起因很好理解,就是有人可以在 repository 裡面放 .GIT 這樣的目錄名稱,配合將大小寫視為一樣的檔案系統 (Windows 系列用的 FATNTFSMac 用的 HFS+),裡面就可以放各種設定值,有機會在 checkout 下來時就執行,或是透過其他的 git 指令執行。

GitHub 在 server 端擋下來了,不過還是建議 client 端趕快更新到最新版,這些版本會從 client 端擋下這些路徑。

這次 CVE 編號是 CVE-2014-9390,不過 NIST 的資料庫裡面沒有列出來?

SSL 3.0 爆炸,CVE-2014-3566,POODLE

這次的慘案是由 Google 的人找到 SSL 3.0 的問題:「This POODLE bites: exploiting the SSL 3.0 fallback」。

Google 提供的解法有兩種。一種是關掉 SSL 3.0,另外一種是關掉 SSL 3.0 的 CBC-mode cipher,但兩種解法都還是會痛:

Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today.

提到相容性問題的原因是 Windows XP + IE6 的組合,在預設安裝下是不支援 TLS 1.0 的 (需要另外打開選項啟用),而看到那個 11.1%:


出自「Internet Explorer - IE 6 Countdown | Modern.IE

另外是 SSL 3.0 如果不支援 CBC-mode cipher 的話,也只剩下 RC4,而這早就千窗百孔了:


出自「Transport Layer Security

也因此,在 CBC-mode cipher 與 RC4 都不能用的情況下,CloudFlare 決定直接關閉 SSL 3.0:「SSLv3 Support Disabled By Default Due to POODLE Vulnerability」。

而其他廠商提供的方案也都差不多,像是 AWS 的「CVE-2014-3566 Advisory」裡建議的解法也是關閉 SSL 3.0:

This includes disabling SSLv3 on both server and client implementations.

新推出的 security policy (ELBSecurityPolicy-2014-10) 裡也直接關掉 SSL 3.0,讓真的有需要的人再手動加上去,或是選擇一月的版本。

SSL 3.0 推出 18 年後總算要被殲滅了...

關於 Shellshock (Bash) 問題

因為 Bash 太多人用,找到安全漏洞的成本效益太高,看起來最近會有大量的人力跳進去 code review,接下來應該是 CVE 滿天飛,跟當初 OpenSSL 的情況類似。

目前建議是直接看維基百科的說明:「Shellshock (software bug)」,裡面直接列出了目前發現的 CVE 以及 attack vector。

會讓管理者想要抱頭痛哭,無止盡的 patch...

Bash 遠端執行安全漏洞

這讓人無言了,Bash 的遠端執行安全漏洞,CVE-2014-6271

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

可以在 oss-sec 上面看到說明「Re: CVE-2014-6271: remote code execution through bash」:

Debian and other GNU/Linux vendors plan to disclose a critical, remotely exploitable security vulnerability in bash this week, related to the processing of environment variables. Stephane Chazelas discovered it, and CVE-2014-6271 has been assigned to it.

透過環境變數打進去... Redhat 的「Bash specially-crafted environment variables code injection attack」這篇也給了不少例子。

Linux 下通常最常用的 shell 應該還是 Bash 吧?(雖然也看到不少人用 Zsh...)

然後 Twitter 上看到非常邪惡的 Google Hack:

大家可以自己加上 site: 去掃...

CVE-2014-0476:掃 Rootkit 的程式變成 Rootkit?

Twitter 上看到居然用這張圖:

CVE-2014-0476 比較完整的說明可以看 Red Hat 的 Bugzilla 上給的說明:「Bug 1104455 – CVE-2014-0476 chkrootkit: local privilege escalation」。

阿彌陀佛...

OpenSSL 安全漏洞 (CVE-2014-0160)

CVE-2014-0160,又稱 Heartbleed Bug,是 OpenSSL 在 TLS 與 DTLS 協定裡的 Heartbeat Extension (RFC 6520) 的錯誤實作。

OpenSSL 官方的 security advisory 在這:「OpenSSL Security Advisory [07 Apr 2014]」,影響的範圍是:

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.

實務上爆炸的程度則是:

A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.

比較有描述性的說明可以參考「The Heartbleed Bug」這個站的敘述:

We have tested some of our own services from attacker's perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.

由於 untraceable,這代表我們必須假設所有受影響機器上的 SSL private key 都已經被洩漏出去了,所有的 key 都必須 revoke 並且重新產生 (& 重新簽)。這兩天讓所有 SA 爆炸的超大新聞...

對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)

在「Disasters」這邊列了不少對稱式加密系統 (secret-key cryptography) 爆炸的歷史,其中提到了很多 Encrypt 與 MAC 結合時的問題 (Authenticated encryption)。另外 Colin Percival 在 2009 年的時候有寫了一篇為什麼要用 Encrypt-then-MAC 的文章:「Encrypt-then-MAC」,當時 Colin Percival 寫的時候大家還是不能理解,但現在回頭看上面的爆炸歷史應該就清楚很多了 XDDD

SSH 協定是使用 Encrypt-and-MAC (傳輸「密文」與「明文的 MAC 值」)。在 2008 年時 SSH 使用 CBC 模式時會有安全問題:對 128bits CBC mode system (像是 aes128-cbc),任意位置的 32bits 有 2-18 的機會可以解出原文。(CVE-2008-5161,論文是「Plaintext Recovery Attacks Against SSH」)

TLS 1.0 (SSLv3) 使用 MAC-then-Encrypt (傳輸「明文與明文的 MAC 值」加密後的結果)。1999 年就知道這個方法不可靠,不過到了 2011 年時才被拿出來示範,也就是 BEAST attack。(CVE-2011-3389,在 ekoparty Security Conference 上的「表演」:「BEAST: Surprising crypto attack against HTTPS」,連結1連結2)

OpenSSLGnuTLS 所實作的 DTLS 在 2011 年也被炸到,其中 OpenSSL 是 100% plaintext recovery,GnuTLS 是 4%。(CVE-2012-0390,論文是「Plaintext-Recovery Attacks Against Datagram TLS」)

而 Encrypt-then-MAC (傳輸「密文」與「密文的 MAC」) 是三者裡面最不容易出包的作法,而且被證明 Provable security:Encrypt 與 MAC 所用的 crypto system 的安全強度不會因為 Encrypt-then-MAC 而減少。而這也是 IPSec 的作法。

附帶一提,其中 Provable security 這個詞,並非表示「可被證明是安全的」,在「In defense of Provable Security」這篇文章裡有比較完整的說明。通常是指安全強度不會因為這個系統而降低:以 Encrypt-then-MAC 的例子來說,如果 Encrypt 的部份用 DES,或是 MAC 用 CRC32,那麼 Encrypt-then-MAC 並不會提供更強的安全性...

總而言之,MAC-then-Encrypt 與 Encrypt-and-MAC 的方式要小心才能避免各種攻擊 (像是不能用 CBC mode),而 Encrypt-then-MAC 可以讓設計協定的人放鬆到「只要 Encrypt 與 MAC 都夠強」系統就沒問題。在 Authenticated encryption 裡提到的 ISO/IEC 19772:2009 支援六個模式,有些有專利問題,有些演算法看起來就很複雜 (於是就容易出包),其中 Encrypt-then-MAC 看起來是個還不錯的方案...

Percona 說明關於為什麼花這麼多時間修正 MySQL 5.5.28 安全問題...

Percona 的 Stewart Smith 解釋為什麼花這麼多時間才修正這個安全漏洞:「CVE-2012-4414 strikes back in MySQL 5.5.29 (and what we’re doing in Percona Server 5.5.29)

MariaDB 的人在得知問題後先建立了 MDEV-382 這個 issue,然後建立了 rpl_mdev382.test 這份測試資料,讓其他參與者可以測試手上的 MySQL 是否有問題。

Oracle 在修正問題時並沒有使用 MariaDB 這份測試資料測過 (或是測過但因為種種因素...) 就推出 MySQL 5.5.29,但 MySQL 5.5.29 用 rpl_mdev382.test 測試會失敗,而實際確認發現 Oracle 並沒有把問題解乾淨。所以本來 Percona 預定要使用官方 MySQL 5.5.29 版本為基礎推出 Percona Server 5.5.29 (可以降低 Percona 維護成本),變成將會改用 MariaDB 的 patch。

讓 Percona 的人特地寫一篇出來,看起來對 Oracle 不太爽... XD