iT邦幫忙

14

為何 OpenSSL Heartbleed 是嚴重又危急的漏洞?

  • 分享至 

  • xImage
  •  

SSL 是網路加密通訊協定。用來確保 client 與 server 間的通訊是加密而不被第三方所窺見的。

OpenSSL 則是實作 SSL 的一個 open source 軟體兼函式庫。許多的 open source 網路軟體都使用 OpenSSL 來實現 SSL 功能。包括知名的 Apache 與 Nginx。只要瀏覽器上的網址列是 https:// 開頭,就是在使用 SSL 加密通訊。
SSL 是網路加密通訊協定。用來確保 client 與 server 間的通訊是加密而不被第三方所窺見的。

OpenSSL 則是實作 SSL 的一個 open source 軟體兼函式庫。許多的 open source 網路軟體都使用 OpenSSL 來實現 SSL 功能。包括知名的 Apache 與 Nginx。只要瀏覽器上的網址列是 https:// 開頭,就是在使用 SSL 加密通訊。

SSL 加密通訊協定的原理,簡單講是下面流程:

  1. client 端向 server 端請求連線,取得 server 端的公鑰。
  2. 如果公鑰經 CA 簽署認證,就繼續執行。若未經合格 CA 簽署,則會出現警告訊息。
  3. 即使不合格,client 可以選擇信任,繼續使用該公鑰。
  4. client 產生一個臨時 session key,以公鑰加密後傳給 server。
  5. server 接到加密 session key 之後,以私鑰解開,得到 session key 明碼
  6. 接下來 server 與 client 就會使用這支對稱式加解密的 session key 來通訊,因為對稱式的加解密非對稱式的加解密要快一千倍,所以非對稱加解密只用在傳送 session key 這一次通訊。

好了。瞭解加解密流程後,接下來就要看它的漏洞在哪。

一般來說,以上流程只有第一步會傳送 request 明碼,接下來就都會在加密過程中進行 (第2步的取得 server 公鑰,此公鑰是由 CA 的私鑰所加密,而 client 端通常已經有 CA 的公鑰了,故可取得 server 公鑰明碼。)。所以過程(演算法)是沒有問題的。

但過程沒問題,不代表化為程式就沒問題。寫過程式的人都知道,在程式的運算中,必須把金鑰、密碼、密文、明文這些東西放在變數中進行運算。也就是會放在記憶體裡。所以,就算程式執行完,得到密文了,有可能加解密的金鑰還在記憶體中,甚至明文也還在記憶體中。所以嚴謹的加解密程式,必須在程式結束時,得把自己用過的記憶體《清理》過,而不是一個 free() 釋放掉就沒事了。

OpenSSL 做為安全通訊函式庫的元老,當然也知道這個問題。只不過,就算最後有做清理,你我都明白,駭客也明白,明文、密碼或金鑰,還是會存留在記憶體一段時間,特別是程式還在執行的時候。所以只要在加解密進行的這時候去記憶體撈,就有可能會撈到寶!也就是明文、密碼或金鑰。對!只要懂這招,那麼世上幾乎沒有一種加密機制可以擋得住你。

本來,加解密也就只在 server 的記憶體中執行,外界的駭客根本無從接觸到。奈何,OpenSSL Heartbleed 有個可超出邊界值的漏洞,原本只是傳給 client 正常資料的通訊,變成 client 可以藉由指定這個沒有檢查邊界值的通訊,而《撈》到 server 記憶體裡的東西。於是嚴重的問題就來了。

  1. 駭客可以側錄到這個沒有檢查邊界值的通訊,並且指定去撈取特定記憶體的內容,假設他撈到 session key,那麼就可以解開這整個 client 與 server 的通訊,包含之前他已經側錄到的密文也能解開成明文。

  2. 若撈到 server 私鑰,那就可以冒充 server。

  3. 若直接撈到 client 的明文,包含登入帳密、個資、信用卡號、... 那後果可想而知。

所以,這問題就跟沒有使用 https 一樣嚴重,甚至更嚴重。因為在 https 之下,通常會傳送更多敏感資料,當然也就被視為有史以來最嚴重的 Bug 了。


圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
Ethan Jhuang
iT邦研究生 3 級 ‧ 2014-04-11 16:08:39

非常感謝您詳細的解說...
學習了讚

我要留言

立即登入留言