Tag: openssl

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 爆炸的超大新聞...

歷史上的爆炸記錄？

在「a brief history of one line fixes」列出了許多經典的問題...

裡面最有印象的還是 2008 年 Debian OpenSSL 問題，也因為這個問題影響太嚴重，後來預設會安裝 openssl-blacklist 這個套件，在連線時檢查是不是有問題的 key...

然後 Android memset() 那個很精彩啊 XDDDDDDDDDDD

Command Line 下把 Hex 轉成 Base64...

每次都忘記，寫一篇之後查比較方便... 重點在對 xxd 的變化應用，而 xxd 被包在 Vim 裡，所以應該都會裝... 吧...

xxd 預設是把 binary 轉成 hex，但你可以用 -r 參數變成反向，也就是 hex 轉 binary。

所以剩下的就很簡單了，先把 hex 轉成 binary 再轉成 base64：

echo 0123456789ABCDEF | xxd -r -p | base64

這邊有裝 Base64 所以可以直接用，如果沒有的話，可以用 OpenSSL 替代：

echo 0123456789ABCDEF | xxd -r -p | openssl enc -base64

OpenSSL 官網被黑...

在 Orange 的 Facebook 上看到的，翻了一下國外的新聞，好像還沒被廣泛報導：「Openssl.org 被改首頁，只維持了幾分鐘XDDD」。

這超精彩的... OpenSSL 耶 XDDD

這陣子國外在放假，反應時間應該會比較慢，過幾天應該陸陸續續可以看到「解說」...

Google 將發現安全問題的獎勵延伸到 Open Source 專案上...

在 Slashdot 上看到 Google 將發現安全問題的獎勵從自家產品延伸到 Open Source 專案上：「Google Offers Cash For Security Fixes To Linux and Other FOSS Projects」。

官方的公告在「Going beyond vulnerability rewards」，規則則是在「Patch Rewards – Application Security – Google」。

初期限制在這些專案上：(直接複製過來)

  • Core infrastructure network services: OpenSSH, BIND, ISC DHCP
  • Core infrastructure image parsers: libjpeg, libjpeg-turbo, libpng, giflib
  • Open-source foundations of Google Chrome: Chromium, Blink
  • Other high-impact libraries: OpenSSL, zlib
  • Security-critical, commonly used components of the Linux kernel (including KVM)

獎勵金額從 USD$500 到 USD$3133.7，這邊的 31337 應該是出自「Leet」吧...

這算是一種回饋社群的方式...

對稱式加密系統的爆炸歷史 (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)

OpenSSL 與 GnuTLS 所實作的 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 看起來是個還不錯的方案...