Re: [心得][.NET] GetHashCode()

[AmosYang (泛用人型編碼器)]

新話題，資訊安全(information security)，開篇新文章 :)

※ 引述《AmosYang (泛用人型編碼器)》之銘言：
:   * C# `System.Valuetype.GetHashCode()` 潛在效能、安全問題
:     http://www.30abysses.com/TWY/2016/11/21/c_sharp-gethashcode-valuetype.html
:
:     ValueType 的 `GetHashCode() 預設實作是把所有欄位(field) 大鍋炒成
:     雜湊(hash)值；有看過些說法主張這可能造成潛在的效能問題外，然而，更嚴
:     重的 是如其原碼註解 所指出的，這多少會在某種程度上把敏感資訊透露出去
:     ，也就是有 **潛在的安全問題** 。
:
:     是故，原碼註解主張
:
:         若此 value type 含有敏感資訊，那它應該為 GetHashCode()  提供自己
:         的實作版本。
:
: 推 james732: 不過有可能從標準實作算出的hash去倒推特定的資料嗎？    11/27 14:22

資訊安全(information security)是很機車的 :D 很難從單一 attack vector  來
評估；每個系統的 threat model 不同，當通常你透露給攻擊者的資訊是愈少愈好

========================================================================

舉個例子，假設要設計個有權限控制的檔案系統；假設有這樣一個檔案

  /foo/bar.txt

假設使用者可以下「讀檔案」的指令

  read /foo/bar.txt

而對沒有權限讀這檔案的使用者，要怎麼回報錯誤？這裡有至少兩個可能性

(1) 「找不到 /foo/bar.txt 」
(2) 「你沒有權限讀 /foo/bar.txt 」

(2) 的 UX  *感覺* 比 (1)  好；然而，若我是攻擊者，即使我沒有權限讀檔案，
我仍能把 (2)  當作 File.Exists(string path) 來用；反過來說， (1)  就沒有
透露出「檔案是否存在？」的訊息。

當然，光是有 (2)  或許不足以造成實質上的破壞，但這裡要說明的，就是「意外
地透露資訊」這個觀念；也就是 (2)  的設計，能讓沒有閱讀權限的攻擊者 probe
整個檔案系統；而有時檔名可能就帶有商業機密 (例如，新產品的 codename )

更有趣的是，這永遠是道高一尺魔高一丈、貓追老鼠的遊戲。例如，就算使用 (1)
的設計，就沒問題了嗎？假如說，以下的情形

  read /foo/bar.txt
  read /foo/non-existing-file.exe

假設 non-existing-file.exe  這個檔案是不存在的，然後又採用 (1)  的設計，
對沒有閱讀權限的攻擊者，兩者都傳回

  「找不到 /foo/bar.txt 」
  「找不到 /foo/non-existing-file.exe 」

Ｂｕｔ！假設系統在處理以下兩個情形所「使用的時間」不同

  (a) 讀本來就不存在的檔案；傳回錯誤
  (b) 讀存在的檔案；讀取使用者身份；讀取使用者權限；比對權限；傳回錯誤

那麼，攻擊者仍能分別出 (a)  與 (b)  的不同；最後這設計仍然「意外地透露
資訊」…

所以說，資訊安全(information security)是很機車的 :D

========================================================================

回到一開始的問題

> 有可能從標準實作算出的hash去倒推特定的資料嗎？

也許大概應該不太可能，但也沒有人能保證 100.00%  零風險。因為你不知道攻擊
者手上有沒有別的資訊(碎片)，就差這一塊就能爆機，所以，還是要
threat model  畫出來，風險評估報告作出來，看 mitigation/isolation/etc.
有的沒的五四三的要怎麼作

反正，誰有那個心臟拿那薪水，誰去簽字負責 :D

--
  個人                                  雜談、學習、英語、軟體
  https://www.facebook.com/tw.yang.30   https://www.facebook.com/30abysses/
  https://twitter.com/twy30             http://www.30abysses.com/

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 70.181.102.71
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1480231756.A.29E.html
※ 編輯: AmosYang (70.181.102.71), 11/27/2016 15:39:51

補述

> 有時檔名可能就帶有商業機密 (例如，新產品的 codename )

像之前 Bandai Namco 出 Summer Lesson  時，就有 *無聊人士* 去研究其日本官
方網站，發現它雖然把 directory listing  關掉了，但從首頁上 Hikari 的人物
圖可以很明顯的看出它的名命規則

  http://summer-lesson.bn-ent.net/images/chara/hikari/img_hikari.png

所以該 *無聊人士* 就寫了個簡單的 script,  拿「2012 日本最常見 50 個女姓
名字去踹官方主機」，看能不能碰巧挖出未公開資訊

雖然最後沒挖出任何東西，但世界上就是有這類 *無聊人士* ，以 exploit  不經
意透露的資訊為樂 :D 而 ValueType.GetHashCode()  的原碼註解就是試著在警告
提醒這種事 :)

例如， **假設**

* http://summer-lesson.bn-ent.net/images/chara/hikari/img_hikari.png  傳
  回 HTTP 200

* http://summer-lesson.bn-ent.net/images/chara/akane/img_akane.png  傳回
  HTTP 404

* http://summer-lesson.bn-ent.net/images/chara/kasumi/img_kasumi.png  傳
  回 HTTP 403

即使讀不到 img_kasumi.png 的內容，攻擊者也知道了 "kasumi" 的存在

※ 編輯: AmosYang (70.181.102.71), 11/27/2016 16:01:51
※ 編輯: AmosYang (70.181.102.71), 11/27/2016 16:09:00
推 Ekmund: 仔細想想 我好像幹過這種事...(" 艸)
推 sing10407: 寫爬蟲的時候最喜歡猜規則了XD
自學起手的碼猴，十個裡面大概有九個有寫過爬蟲抓圖的程式或 script...  剩下
的那一個直接架站 :D

推 sivid: 好文推推
推 SeaSprite: Very well said!
推 mummyqq: 說的真好
→ yyc1217: 但一律回傳404會讓工程師很難debug 建議還是要有log
推 zombiesky: 回樓上 可以讓開發模式和正式模式 回傳不同訊息
是的，不同的危機等級，有不同的作法。在商業上也有反向操作，故意流出資訊，
製造 hype 的作法 :D 這篇文的起源是 ValueType.GetHashCode()  的作者無法預
測所有的情形，所以只是用 "should" == "應該" 建議一個作法。

題外話，關於規格書中 should/should not/must/must not  這類用詞，可以參考
這篇 RFC

  https://www.ietf.org/rfc/rfc2119.txt

有更詳細的說明 :)
※ 編輯: AmosYang (70.181.102.71), 11/28/2016 05:01:39

這篇文整理後收錄於

  http://www.30abysses.com/TWY/2016/11/28/information-security.html

另外寫了篇文，簡介 RFC2119

  http://www.30abysses.com/TWY/2016/11/28/rfc2119.html
※ 編輯: AmosYang (70.181.102.71), 11/29/2016 14:29:59
推 zanyking: 推！