爆炸，解體，入侵，你想得到的你想不到的大BUG們

鄭昀 創建於2017/9/29 最後更新於2017/10/6

提綱：

1. 阿麗亞娜火箭的解體
2. 阿波羅飛船的P01模式
3. 德勤的Google+
4. 麻省理工的500英里郵件

又到了扶額興嘆的節氣。（前文回顧：5年前的今天，一個小小的部署錯誤，讓美股最大交易商墜入深淵）

0x00 阿麗亞娜火箭的解體

1996年6月4日，阿里亞娜五號火箭首次測試發射。

37秒後，火箭水平翻滾，解體爆炸。

WHY？

Ariane 的開發語言是 Ada，美國軍方軟體開發強制語言，。

設計 Ariane4 火箭的時候，設計師們堅信水平速率是不會超過一個16-bit signed integer 的。

但 Ariane5 火箭的水平速率比 Ariane4 高出了5倍，code review 時，大家都沒有注意到這一點。

16位整型的範圍是 -32768 到 32767。

出錯的代碼是：

horizontal_veloc_bias := integer(horizontal_veloc_sensor);

昀哥查了查事故報告，引發問題的是 BH, Horizontal Bias。

這個值與時間有關，還不是純水平速度。

因為 Ariane5 的早期軌道與 Ariane4 不同，所以這個 BH 比預想的高了很多。

結果導致數據轉換時溢出。

控制慣性導航系統的計算機向控制引擎噴嘴的計算機發送了一個無效數據。

於是火箭偏離它的飛行路徑，解體並爆炸。

嗯哼，所以有一個段子說，如果阿麗亞娜火箭的開發語是 JavaScript，就不會發生這個慘案。

0x01 阿波羅飛船的P01模式

話說史上最牛的女程序員瑪格麗特·希菲爾德·漢密爾頓（Margaret Heafield Hamilton）在1965年擔任 NASA 軟體編程部的部長。

軟體工程（Software Engineering）這個詞就是瑪格麗特·漢密爾頓發明的，不過那已經是阿波羅11號飛船期間的事情了。

下面我們要講的是阿波羅8號飛船的故事。

那個時候她沒日沒夜地工作，女兒勞倫就在她的實驗室玩耍，累了就在地板上睡覺。

這一天，勞倫在指令艙模擬器里按來按去，居然啟動了一個叫 P01 的預處理程序。

頓時模擬器就崩潰了。

瑪格麗特發現後，就建議加段代碼防止此情況出現。

但是大家都覺得航天員不可能這麼操作，這個異常處理完全沒必要。

主要是因為當年的計算機存儲空間和運算能力十分有限，螺螄殼裡做道場，斤斤計較的領導不願意浪費這個空間。

所以瑪格麗特只好加了一個備註：不要在飛行中選擇P01模式。

但是，想啥就來啥。

1968年12月26日，人類首次繞月飛行的阿波羅8號飛船上，航天員還是成功地進入了 P01 模式。

這個模式啟動的直接結果就是：所有導航數據都會被清空。

航天員再也別想回家了。

瑪格麗特帶著人奮戰了9個小時，終於上傳了新的導航數據，一切又回到正常的軌道，阿波羅8號也順利載著宇航員返航。

這事兒沒完，在阿波羅11號飛船即將登陸月球前的幾分鐘，又一個更大的危機發生了。

欲知詳情，請在搜索引擎搜索關鍵詞「程序員永恆的女神」。

0x02 德勤的Goolge+

昀哥以前在《安全基礎教育第一季》里說過，當公司做得越來越大的時候，總會出現那麼幾個安全意識薄弱的人員（俗稱豬一樣的隊友），他們往往會做出一些讓人無法理解的事情，比如：他會毫不猶豫地雙擊運行郵件內的 EXE 附件，或者使用跟用戶名一樣的密碼，或者用戶名+當前年份的密碼。

而且每家知名公司都有這麼幾個沒心沒肺的人，在開源社區泄露源碼或敏感信息，在烏雲網裡隨便一划拉就能找到好多：

盛大某開發人員意識不足泄漏內部郵箱帳號密碼（github）

迅雷某開發人員意識不足泄漏內部郵箱帳號密碼（github）

一次成功的漫遊京東內部網路的過程（由一個開發人員失誤導致）（github）

新浪開發人員安全意識不足導致部分源碼泄漏（googlecode）

騰訊多組內部郵箱賬號密碼泄漏（github）

……

為什麼要刻意強調這一點？

因為 github 支持強大的搜索語法，可以很方便地搜索到一些常規搜索引擎無法搜索到的內容，如搜索內部項目、密碼、密鑰等。

你可以通過 github 來查找代碼安全問題，如輸入規則：extension:php mysql_query $_GET，可以搜索到大量包含 mysql_query $_GET 的請求，可以有針對性地進行代碼審計。

當你把自己的項目代碼上傳到 github 時，看看配置文件里是不是有不能說的秘密，思量一下後果。

這不，一位德勤員工據信在2016年Q4或更早將公司代理登錄憑證上傳至他的 Google+ 上，從而引發了2016年年底到2017年年初的德勤全球電子郵件伺服器及其他內部系統被入侵。

有時候你很難理解人們的想法。

在中國，有位官員甚至把微博當成是私密日記本，發布了不少他的私下裡的勾當，還配了圖……

這位德勤員工可能也以為別人看不到他的 Google+ 信息吧。有圖為證：

以及

Google+ 頁面上的信息是 public 的，所以有心人已經收集到了德勤內部遍及全球的大量伺服器信息，這些信息足以讓有心人對德勤發起一次攻擊。

這也就是為什麼新員工報到之後，我先做一次安全基礎教育培訓的緣故。

0x03 麻省理工的500英里郵件

這個故事不知道發生於何年何月，發帖人是一位擁有豐富 Unix/Linux/Perl 經驗的系統工程師 Trey Harris，據信是上世紀90年代的事情了。

麻省理工的一位統計系主任打電話給 Trey：「我們的郵件系統存在一個問題，我相信我們不能發送超過500英里距離的郵件。」

WTF？！

Email？不能超過500英里？！

「真的，哪怕再遠一點點，只能到520英里了，不能再遠了。」

Trey 幾乎不敢相信自己的耳朵。

這是麻省理工的系主任該說的話嗎？

「是什麼讓你這麼認為？」

「實際上已經好幾天了。你看，直到剛才，我們才收集到足夠多的證據。我讓一名地理統計人員去調查了這件事情。」

這回聽上去像是一名統計系系主任該說的話了。

「還有。她製作了一張地圖，地圖上顯示我們能發送郵件的區域半徑比500英里多那麼一點點。即便如此，這個區域內，有些地方也不能發送，或者偶發性地能發送，但是在區域之外從來沒有發送成功過。」

是的，作為一名豐富經驗的系統工程師，Trey 不假思索地問：「這段時間內系統發生了什麼改變嗎？」（因為下一句話就一定是請你重啟系統吧，XD）

「沒錯，一位技術支持來過，給系統打過補丁並且重啟，之後就發生了這一切。」

Trey 決定自己試一試，今天並不是愚人節。

千真萬確，紐約（420英里）就可以發送，但是普羅維登斯（580英里）就失敗了。

Trey 證實了這個問題現象跟收件人的位置有關係，與收件人的 ISP 關係不大。

Trey 看了一下 sendmail 的配置文件，毫無意外地，它們正常得不能再正常了。

見鬼了。

於是 Trey 遠程登錄到 SMTP 埠，握了握手。

對端用一個 SunOS sendmail 標識愉快地做出了響應。

SunOS sendmail 標識？！

突然之間，水落石出。

這個水落石出有點出人意料，下面這段話估計只有系統工程師才能理解：

技術支持工程師打補丁的時候，還連帶升級了 SunOS 的版本。

因為在那個年代，Sun 仍然隨同操作系統捆綁發布 Sendmail 5 版本，儘管 Sendmail 8 已經相當成熟了。

這樣一來，他等於把原來的 sendmail 8 「降級」為 sendmail 5 了。

但升級程序將 sendmail.cf 配置文件單獨保留了下來。

注意這可是 sendmail 8 的配置文件喔。

一般來說，較低版本的程序看到不認識的配置項，通常都會選擇忽略。

而 sendmail 的二進位安裝包對大多數選項沒有提供默認值，因此，如果在 sendmail.cf 中找不到相應的設置，它們就會被默認設置為0！

就這樣，有那麼一個重要的參數：連接遠程 SMTP 伺服器的超時時間，也被默認設置為零。

經過實驗證明，在一個具有典型負載的特定機器上，零超時意味著如果連接時間稍微超過3毫秒，伺服器就會終止 socket 連接。

在當年，麻省理工的校園網路它是百分之百交換型網路（it was 100% switched）。

這意味著，它沒有那麼多的 router，也就沒那麼多網路延遲。

發送出去的數據包，在遇到 POP 伺服器和遠端路由器之前，就不會出現路由器延遲。

所以連接一個遠端主機的時間，很大程度上就是光所需的時間。

那麼，3毫秒，光能跑多遠呢：

=299792458米/秒×0.003秒×0.001×0.6213712（註：公里摺合英里）

=558英里。

XDD……

-EOF-附贈福利：5年前的今天，一個小小的部署錯誤，讓美股最大交易商墜入深淵-

歡迎訂閱我的微信訂閱號『老兵筆記』

http://weixin.qq.com/r/50Omvs7EHZNirYrd9xb1 (二維碼自動識別)