甲骨文：不行，你不能看我們的原始碼！

黃小非發表於2015-08-15

是人寫的軟體，都不可避免有漏洞。而發現漏洞的，並不只是軟體開發商，也有獨立第三方機構或個人。所以，業界不少知名公司有對外的漏洞懸賞計劃，比如：Facebook 、谷歌、Twitter、微軟、Paypal。

咦，為啥小編沒聽過甲骨文的漏洞懸賞計劃呢？各位接著往下看。

8月10日，甲骨文 CSO（首席安全官）Mary Ann Davidson 在企業部落格上釋出一篇文章，怒斥客戶通過逆向工程看原始碼找漏洞的行為。這篇文章在 Reddit 引發大量討(tu)論(cao)，本文末尾摘錄的 3 條。該文因爭議太大，後來被刪，不過有谷歌快照 & 時光機存檔了。

下面是伯樂線上翻譯組黃小非的全文翻譯。

Mary Ann Davidson

No, You Really Can’t | 不行，就是不讓你看

我最近已經寫了很多東西了。其中一些是和我姐姐一起，使用筆名Maddi Davidson寫的凶案懸疑小說。最近，我們一直在寫一些較短的凶殺故事，嘗試用一些新主意來“殺死”故事中的被害者（誠實地說，在現實中我真會去想怎麼把這些凶殺情節實踐到那些連車距都保持不好的白痴司機身上)。

對於我來說，寫懸疑小說真的比我寫其他型別的東西要有趣得多。最近我發現，企圖通過逆向工程來挑我們毛病的客戶人數顯著地增加了（誒，大大嘆口氣吧）。所以你也就不難理解為什麼我近來大量給客戶寫信，都是以這樣的內容來開頭：“Hi~, Howizt，你好”（譯註：看似很友好客套），可是結尾卻變成了：“請您遵循許可證協議，不要再對我們進行逆向工程看原始碼了。”

我能理解，在我們生活的世界上，幾乎每天都有人在說資料出了問題，然後還會有超級無敵多的匿名入侵記錄，這一定是敵對分子搞破壞造成的。所以，在系統安全技術方面人們總是想再往前多走一步。不過，在你整裝待發準備多走這一步之前，你要知道，其實客戶已經標定了關鍵系統，對敏感資料進行了加密，該打的補丁都打上了，而且也配備了各種配套產品，並且還用了工具來鎖定配置確保其不會被篡改——總而言之，在你嘗試挖掘 0-day 大漏洞之前，系統在常規情況下已經非常安全了。事實上，如果該做的常規措施都做到了，大部分的資料隱患都可以被消除，這個事實聽上去一點兒也不性感吧，但事實就是這樣，通常情況下那些用 0-day 級別漏洞來產生的“無敵高階持續性系統威脅“的案例並非真的存在！所以無論是你自己去打理伺服器，還是說你的雲服務供應商幫你去鼓搗，把基本的安全實踐工作做好非常必要（，其餘的事情你就不用去考慮了）。

縱使認為供應商都應該是業界良心（會對他們的開發軟體產品的方式負責），你還是有很多東西需要確認，而不能只用漏洞掃描工具一掃了之。客戶能做的事情可多著呢，額滴神啊（千萬別說你不知道該做什麼），客戶可以詢問供應商，問問他們採用了哪些安全認證規程，或者查檢視他們的產品有沒有行業認證（例如像 Good Housekeeping 質量擔保圖印，或者 FIPS-140 認證這樣的計算機資訊保安通用標準認證）。大多數供應商，至少是我知道的最大的那幾個供應商，目前會採用相當完備的安全規程（我之所以知道這些資訊，是因為我們在技術大會上會相互交換技術資料並作比較）。作為客戶，在安全方面孜孜不倦當然是好事，不過如果客戶總是想著：“嘿，我認為我應該幫供應商做點兒什麼，所以讓我來看看他們的原始碼有什麼漏洞沒有”，這樣就不是什麼好事了。即使是面對如下的情況，這也不是什麼好事：

漏洞掃描工具報警：客戶其實沒有能力去分析被報警的部分是否是在安全控制範圍之內的，更何況這種報警往往還都是“虛假警報“（false positive）
即使發現問題，客戶也沒有能力去自己給問題開發補丁程式——因為只有供應商才有能力開發補丁程式
客戶在使用靜態工具分析原始碼時，實際上很可能已經觸犯了許可證協議條例（條例規定不能對原始碼進行任何操作）

我來開門見山地說吧：我認為很多時候說”客戶使用逆向工程技術”這句話其實並不準確，因為真正的逆向工程操作是由客戶聘用的顧問來做的，這些顧問執行一下逆向工具，逆向出一堆程式碼，用印表機列印出一大坨，往客戶面前一撂，接下來客戶就會把這一大坨送給我們。我現在已經注意到，給我們送來的所謂漏洞掃描報告根本就不是“證明這裡或者那裡有問題”的清晰報告，不管是採用動態分析還是靜態分析，漏洞掃描報告完全不體現漏洞存在的真正證據。通常情況下，這些報告就跟一縷蒸汽一樣（撲朔迷離又沒有價值）。

沒事兒找事。(是的，我打算一直這麼說：沒事找事。) 這就是為什麼我們要求客戶舉報每一個所謂”問題“時，都必須填寫服務申請（而不是僅僅把漏洞報告扔給我們就完事兒了），同時還要提供概念性的證據（確實有一些工具能做到這一點）。

通過我們自己的分析，如果我們真的認定掃描報告的結果只可能來自於逆向工程（我們至少遇到過一次以上這種案例，因為報告上“很聰明地”寫了：“通過對Oracle XXXXXX 軟體的靜態分析……”），那麼我們就會立刻給“有罪”的客戶寫信，並同時給為“有罪客戶”提供諮詢的“有罪顧問”另去一封信件，提醒他們已經觸犯了Oracle許可證協議中禁止使用逆向工程的條款，所以不要再這麼做了。（用正規的法律語言來說，Oracle許可證協議上的條款是這麼寫的：“使用者不得進行逆向工程，反彙編，反編譯，以及任何從程式中獲得原始碼的嘗試”，我們在給客戶的警告信中就會引用這個條款）。哦，我們還會要求客戶/顧問銷燬從逆向工程得來的結果，並要求他們確認他們執行了銷燬。

為什麼我要強調確認銷燬呢？最主要的原因是，我要把這個事情做得板上釘釘。我可不想為了“你們觸犯了許可協議”，“不我沒有”，“有的，就就是有”，“不，我們沒有”這種來回扯皮的話浪費時間。我寧願花更多我自己的時間，以及團隊的時間，去幫助提升開發程式碼的質量，而不是和人們去討論使用者許可證協議細節問題

現在我需要重申一下，我在這裡並不是要用許可證協議來打壓使用者。我其實更想說的是，“我不讓你去分析程式碼，是因為我自己會去分析。分析程式碼是我的工作，我們很擅長我們的工作。我們能切實對程式碼進行分析，並弄清楚真正的情況是什麼，而第三方諮詢機構或者其他工具軟體則做不到。無論在何種級別上，這些工具軟體找出來的所謂‘漏洞’幾乎 100% 都是‘誤報’。所以不要再浪費你的時間了，那些工具裡面的小綠人報警幫不了你任何忙。” 我不是要逃避我對客戶應盡的運維責任，我僅僅是想避免那些痛苦、煩躁又讓雙方都非常不爽的過程。

基於上述原因，我想解釋一下 Oracle 實施使用者許可證條款（尤其是關於逆向工程的條款）的目的，其實這個目的非常符合邏輯也非常符合直覺，那就是：“我們告訴你我們的底線在哪兒，一旦你越過了，我們就對你不客氣。” 附註：我在日常與人交談時偶爾會用到 stare decisis（譯註：拉丁文，意思是“照章辦事”）這種法律專業詞彙（不過我的狗完全不懂拉丁語，它只明白夏威夷語），不過我畢竟不是律師（譯註：作者的意思是，他的觀點並不能代表Oracle對這些問題的官方司法解釋）。所以，當你有什麼疑問的時候，參照 Oracle 許可證條款原文就好了，原文比我在這篇文章裡寫的要準確嚴格得多。

依照上面說的那些原則，我列出一些 FAQ 問答形式的文字，用來做為解釋：

問：什麼是逆向工程？

答：總的來說，我們（Oracle）的程式碼都是編譯（是的，我知道有些程式碼是解釋型的）以後（以可執行的方式）交付使用的。客戶拿到的是可執行的程式碼，而不是程式碼在“被開發”時的形式。使用者絕大多數時候只需要執行程式碼，而不需要了解程式碼是怎麼拼湊在一起工作的。這樣做的理由很多，例如事實上，我們的原始碼是非常寶貴的知識財富，受智慧財產權法保護（所以我們會對能夠接觸到原始碼的人群設定重重限制，就是為了保護原始碼的智慧財產權）。Oracle許可證協議限制了你只能使用交付形式的程式碼，這一限制隱含著一個事實概念，那就是你不能夠反編譯，反彙編，不允許把故意做擾亂處理的程式碼復原，不允許用任何其他形式的將程式碼從可執行形式轉變會原始形式。儘管對於這些限制會有一些特別註釋，但是也絕對不會出現“只要你是在尋找程式碼漏洞就萬事大吉”這種例外情況。

所以說，如果你要嘗試把我們賣給你的程式碼轉變成與我們賣給你時不同的形式——比如，轉變成在我們寫這些程式碼，並且還沒有通過對他們進行加工然後賣給你的那種形式，那麼你就很可能是在逆向工程了。不！要！這！麼！做！

問：Oracle關於提交安全漏洞的協議是怎麼規定的呢（是不是允許使用工具呢？）

答：我們需要客戶針對每一個漏洞做一個上報申請，並提供測試用例，證明你所謂的安全漏洞是可被偵測到的。我們之所以採取這種策略的原因，是為了篩除大量採用安全工具軟體掃描得出的不準確的漏洞資訊（也就是誤判的漏洞資訊）。

問：為什麼你們（Oracle）要去找那些客戶的顧問的麻煩呢？客戶的顧問又沒跟Oracle籤什麼許可證協議。

答：顧客是同Oracle簽訂過許可證協議的，那麼由顧客僱傭的顧問就因此具有了連帶簽訂許可證協議的法律關係。要不然的話，豈不是每個受僱於客戶的顧問都可以說（注意，下面是法律咒語）：“甲方甲方能力差，顧問顧問最牛叉，甲方不能我偏能，我想幹啥就幹啥”。

問：如果真的有使用者發現了安全漏洞，Oracle會怎麼處理的呢？

答：每當被問到這個問題的時候，我的第一反應是拒絕的。因為我想再次重申，使用者不應該也不允許對我們交付的程式碼進行逆向工程。然後，如果真的有客戶發現了貨真價實的安全漏洞，我們就一定會去修復。我們不喜歡從使用者那裡發現漏洞（我知道這種說法很可能得罪人），但是如若真的發現了問題，我們也不能熟視無睹。然而，（從另一種角度看）我們去修復錯誤，也是在保護我們其他的客戶，因為一旦我們修復了錯誤，其他客戶的錯誤也同時得到了修改。不過，我們是不會給上報漏洞的客戶（如果他們真的是通過逆向工程來發現漏洞的）提供專門（一次性）補丁的。在釋出的公告中，我們也不會（給違規上報者）提供任何讚譽。所以你就不要指望我們會對你說：“感謝你破壞了我們的許可證協議“了。

問：現在的反編譯產品越做越好，上手也越來越容易，所以說是不是以後的某一天逆向工程就變得OK了？

答：啊，不會的。我們對於逆向工程的反對是基於保護智慧財產權的立場的，我們並不是要證明“我們把聰明才智都發揮在阻止我們的客戶發現我們安全漏洞上，即使發現了漏洞我們也不修復”。我們鼓勵客戶在可執行程式碼上使用工具進行評估，只是說不要去逆向工程就可以了。從這一點來看，使用者通過使用第三方工具或者服務來發現問題也是有可能得到我們的優質服務的，只要你跟你的工具開發商或者服務供應商確認一下：a) 工具的工作原理是什麼 b) 他們是否實施了逆向工程來達到目的。不管他們說得怎麼天花爛墜，你只要記住，問題正確的答案就只有幾種情況：“不，我們沒有做”；“是的，你做了”；“沒做”；“做了”。（譯註：其他的答案都是忽悠你的或者是廢話）

問：不過我的編碼顧問/第三方漏洞掃描軟體真的很牛。你們Oracle就不能把我提交的400頁的漏洞掃描報告好好分析一下嗎？

答：嘿，哥們兒。我覺得我說這件事情已經說了這麼多遍，我都快成說唱歌手了：我們Oracle自己有自己的程式碼靜態分析工具（而且是我們自己開發的），我們自己會分析！外面的那些垃圾工具真的是不準確到離譜啊！（有的時候誤判率居然達到了100%，或接近100%），況且用軟體工具掃描這件事情本身並不重要。重要的是你要有分析掃描結果的能力，諸如此類。如果我們花時間去判斷客戶或者他們的顧問的指指點點，分析那些毫無意義的東西，那完全就是一種浪費。我們應該把我們的時間花在刀刃上，也就是說，花在去找那些真正的漏洞上面去。

問：是不是一旦有人發現了真正的漏洞存在，你們就會說他們是通過逆向工程才找到的啊？

答：誒，我可是冒著被人罵囉嗦的風險再跟你們說一次：不，不是的。就好比如果有人家裡的門或者窗戶沒鎖，那麼你直接進入就不算非法闖入。雖然我們不敢說用過市面上每一款的掃描工具。不過我們確實要求開發組（連帶包括雲端開發和內部開發機構）多用漏洞掃描工具，我們過去幾年在工具使用方面已經取得了長足的進步（看看我們的指標資料就知道了），並且我們把跟蹤工具的使用納入到了“Oracle軟體安全確認規程”當中。我們強迫——我的意思是“要求”——開發團隊使用漏洞掃描工具，是因為我們非常願意（當然我們的客戶也非常願意）儘可能早地發現並修復各種問題。

業界有云：沒有一種工具是萬能的。實際上幾種工具加起來也達不到萬能。我們做不到萬能，不過這並不能說使用者試圖通過逆向工程來找我們的漏洞就是正確的。其實分析一個疑似的漏洞究竟是不是真正的漏洞，最關鍵的就是對原始碼進行分析。坦率地講，第三方軟體是很難做到從原始碼的角度進行分析的。隨便哪個客戶用逆向工程工具粗淺掃描一下，就給我們發漏洞報告，我們自然是不能接受，原因很簡單，我們並不需要這樣的報告。

問：嘿，我有個主意，幹嘛不搞個bug懸賞活動呢？如果第三方幫你們找到漏洞，你們給他們獎金不就可以了？

答：誒（再次大口嘆氣）。Bug懸賞活動是給那些玩票兒的人準備的（玩票兒這個詞兒不錯吧，是不？）。好多公司把自己和安全研究員都搞得跟神經病一樣，讓他們來找公司產品程式碼中的問題，然後還堅持認為：這才是解決Bug的終極之法，就得這麼幹：如果你不搞Bug懸賞活動，那你就沒法做到程式碼安全。啊，好吧，其實我們87%的安全漏洞都是我們自己找到的，我們的安全研究員會找到約3%的漏洞，剩下的漏洞則是通過使用者來發現的。（這裡跑個題：我今天發現，一個還挺有名氣的安全研究員上報說，在某個特定的技術領域他發現了一堆所謂漏洞，希望我們引起注意——實際上我們早就發現了全部的漏洞，現在已經在著手修補，或者都搞定了。哈哈哈，這件事情笑得我胸圍都變大了！）

我並不是要貶低Bug懸賞活動，只是這麼做毫不符合經濟學邏輯，我為什麼要花錢去請一個只能解決我3%問題的人（並且還不能持續性解決問題，基本上就像打田鼠一樣看一隻打一隻），我有這些錢還不如其再聘請一個全職僱員，讓他去做一些合規的hacking，然後為我們開發出好用的工具，從而能夠自動發現並解決某個特定型別的問題，這樣才是正確的做法。其實這個問題就是一個“該信基督教還是該信天主教”的問題，我們當然會包容不同的宗教和文化，但是我們會用我們的方式來包容——其他人怎麼做那不關我們的事。祝你們平安！

問：如果你不讓客戶去做逆向工程，萬一他們生氣了不買你們的東西了咋辦？

答：的確我們聽到過類似的說法。不過諷刺的是，就是因為他們願意買我們更多的產品（或者使用我們的雲服務），才必須跟我們籤使用許可協議啊！所以他們這麼想就已經是在違背許可證協議了啊。“親愛的，如果你不讓我再次背叛你的話，那麼我們的愛情就能天長地久”，“啊，額，你已經違反了婚姻誓詞裡面‘無論如何都會天長地久’的誓言了啊，所以我們的婚姻完了”。

同客戶溝通更好的方式——通常我也會這麼做——就是跟他們解釋我們會對我們的產品充分負責，包括我們自己會開發漏洞掃描工具。我希望使用者對我們的產品和服務有信心，而不是需要老給他們寫信提出警告。

問：好吧，你們可以說那些壞人以及競爭對手會去對Oracle的程式碼進行惡意逆向工程，而且也不會在乎你們的許可協議，不過還是有些客戶是出於好意的吧，對於這些人你們也要限制嗎？

答：Oracle許可證是為了保護智慧財產權的目的而存在的。而第三方掃描我們程式碼的行為被稱之為”好意“，我覺得這種觀點需要修正，任何為侵犯許可證協議的行為找藉口都是不可接受的。就像是你不能跟你的配偶說：“別人家都出軌了”，這完全不是一個正當的理由，因為結婚的時候這些約束都是定好了的。

寫到這裡，我覺得我可以下個定論了，或者說可以拍板了。我們要求客戶不能對我們的程式碼進行逆向工程，從而找什麼安全漏洞。我們自己有原始碼，我們自己會執行掃描工具分析自己的原始碼（當然我們同時也會分析可執行程式碼），所以分析程式碼這件事情真的是我們的事情。我們不需要客戶，或者天知道哪兒來的一個第三方機構通過逆向工程來幫我們找漏洞。最後，但是也是最重要的，Oracle許可證協議禁止你這麼做。所以你們就不要去做了就對了。

* 我覺得肯定有一部分客戶來回地罵我，因為這些客戶已經給他們的顧問付了一大筆諮詢費了。他們會覺得是因為我們（無能導致漏洞產生）讓顧問們敲了他們一大筆（其實是顧問違反了許可證協議在先）。

** 我能想到的唯一的比喻是，我的書架。有的人看了我書架上的書名，就會覺得我是一個好色之人，喜歡看色情小說。並且他們還會讓我解釋，為什麼我要買這麼一堆奇奇怪怪的書。比如這些例子（這些真的是我書架上的書的名字哦）

1. 來自下方的雷霆一擊（額滴親孃，一定很勁爆）

2. 裸體經濟學（“裸體主義哦！”）

3. 地獄烈火（“哇，一定更勁爆”）

4. 黎明，我們睡去（“你一定是昨天晚上運動過度了才會熬到黎明都不睡吧”）

對於這些，我的迴應是，我可沒義務給你們解釋我對圖書的品味，我也不會去真正迴應這些懷疑。（不過你們如果真的感興趣的話，我就告訴你們吧，1. 這是一本傳記書籍，書的主人公是 Eugene Fluckey 艦長，第二次世界大戰美國海軍潛艇艦長，國會榮譽勳章獲得者。2. 這真的是一本經濟學書籍。3. 這是一本介紹二戰期間歐洲劇院的書籍。 4. 這是一本描述珍珠港事件的作品。

***我怎麼會討厭凱恩斯（英國著名現代經濟學家——譯者注）呢！！！世界上現存的渡渡鳥（一種珍稀動物，已滅絕——譯者注）的數量都比凱恩斯乘數理論的支持者要多。據我所知，“渡渡鳥”和“凱恩斯乘數原理支持者”這兩個詞彙都能當同義詞使用。

****當然，我可能有點誇張了。但也許沒有。

補充1：摘錄 Reddit 網友的吐槽：

gaggra：

這篇博文口氣真是傲慢、無禮、假仁假義，我肯定該文要被甲骨文的公關撤下了，因為這真是一篇爛稿。

joeflux：

文章中指出，客戶發現的漏洞數量（10%）是他們自己安全人員發現的 3 倍。他們是怎麼響應的？給客戶發威脅信。

willvarfar：

So is Oracle’s packaged-up Linux distro only “Unbreakable” in a legal sense, then? ;)

http://www.oracle.com/technetwork/topics/security/securityfixlifecycle-086982.html says 甲骨文在這篇文章說過

Oracle appreciates and values the members of the independent security research community who find vulnerabilities, bring them to our attention, and work with Oracle so that security fixes can be issued to all customers. 甲骨文讚賞並重視發現漏洞的獨立安全研究社群……

So there’s some kind of disconnect going on here anyway.