由蘋果的低級Bug想到？
2014年2月22日，在這個“這么二”的日子里，蘋果公司推送了 iOS 7.0.6（版本號11B651）修復了 SSL 連接驗證的一個 bug。官方網(wǎng)頁在這里：http://support.apple.com/kb/HT6147，網(wǎng)頁中如下描述：
也就是說，這個bug會引起中間人攻擊，bug的描述中說，這個問題是因為miss了對連接認證的合法性檢查的步驟。
Impact: An attacker with a privileged network position may capture or modify data in sessions protected by SSL/TLS
|
這里多說一句，一旦網(wǎng)上發(fā)生任何的和SSL/TL相關的bug或安全問題，不管是做為用戶，還是做為程序員的你，你一定要高度重視起來。因為這個網(wǎng)絡通信的加密協(xié)議被廣泛的應用在很多很多最最需要安全的地方，如果SSL/TLS有問題的話，意味著這個世界的計算機安全體系的崩潰。
Bug的代碼原因
Adam Langley的《Apple’s SSL/TLS bug 》的博文暴出了這個bug的細節(jié)。（在蘋果的開源網(wǎng)站上，通過查看蘋果的和SSL/TLS有關的代碼變更，我們可以在文件sslKeyExchange.c中找到下面的代碼）
- static OSStatus
- SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
- uint8_t *signature, UInt16 signatureLen)
- {
- OSStatus err;
- ...
- if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
- goto fail;
- if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
- goto fail;
- goto fail;
- if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
- goto fail;
- err = sslRawVerify(ctx,
- ctx->peerPubKey,
- dataToSign, /* plaintext */
- dataToSignLen, /* plaintext length */
- signature,
- signatureLen);
- if(err) {
- sslErrorLog("SSLDecodeSignedServerKeyExchange: sslRawVerify "
- "returned %d\n", (int)err);
- goto fail;
- }
- fail:
- SSLFreeBuffer(&signedHashes);
- SSLFreeBuffer(&hashCtx);
- return err;
- }
注意，我高亮的地方，也就是那里有兩個goto fail; 因為if語句沒有加大括號，所以，只有第一個goto是屬于if的，而第二個goto則是永遠都會被執(zhí)行到的（注：這里不是Python是C語言，縮進不 代表這個語句屬于同一個語句塊）。也就是說，就算是前面的if檢查都失敗了（err == 0），也會goto fail。我們可以看到fail標簽中釋放完內(nèi)存后就會return err;
你想一下，這段程序在SSLHashSHA1.update() 返回成功，也就是返回0 的時候會發(fā)生什么樣的事？是的，真正干活的 sslRawVerify()被bypass了。而且這個函數(shù) SSLVerifySignedServerKeyExchange() 還返回了0，也就是成功了！尼瑪！你可能想到酷殼網(wǎng)上之前《一個空格引發(fā)的慘劇》的文章。都是低級bug。
這個低級bug在這個周末在網(wǎng)上被炒翻了天，你可以上Twiter上看看#gotofail的標簽的盛況。Goto Fail必然會成為歷史上的一個經(jīng)典事件。
如果你喜歡XKCD，你一定會想到這個漫畫：
注意：這個bug不會影響TLS 1.2版本，因為1.2版本不會用這個函數(shù)，走的是另一套機制。但是別忘了client端是可以選擇版本的。
如果你想測試一下你的瀏覽器是否會有問題，你可以上一下當天就上線的 https://gotofail.com 網(wǎng)站
一些思考
下面是我對這個問題的一些思考。
0）關于編譯報警
有人在說蘋果的這個代碼中的goto語句會產(chǎn)生死代碼——dead code，也就是永遠都不會執(zhí)行到的代碼，C/C++的編程器是會報警的。但，實際上，dead code在默認上的不會報警的。即使你加上-Wall，GCC 4.8.2 或 Clang 3.3 都不會報警，包括Visual Studio 2012在默認的報警級別也不會（默認是/W3級，需要上升到/W4級以上，但是升級到/W4上，你的工程可能會有N多的Warning，你不一定能看得 過來）。gcc和Clang有一個參數(shù)叫：-Wunreachable-code，是可以對這種情況報警的，但即沒有被包括在-Wall里。原因是，這個 參數(shù)有很多的問題，因為編譯器的優(yōu)化代碼的行為，這個參數(shù)并不能對每種情況都準確地報告。另請注意，GCC的新版本中剔除了這個參數(shù)。當然，其它一些靜態(tài) 的代碼檢查工具也可以檢查這個低級的問題。
另外，是不是用IDE的代碼自動化格式工具也可以幫上一點忙呢？至少可以把那個縮進變成讓人一看就覺得有問題。
1）關于Code Merge 和 Code Review
你可以通過這里的代碼比較看到這個bug的diff，也可以到這里看看（631行）。
- diff -urN <(curl -s http://opensource.apple.com/source/Security/Security-55179.13/libsecurity_ssl/lib/sslKeyExchange.c\?txt) \ <(curl -s http://opensource.apple.com/source/Security/Security-55471/libsecurity_ssl/lib/sslKeyExchange.c\?txt) \
通過code diff你可以看到，蘋果公司是在重構代碼——為很多函數(shù)去掉了ctx的參數(shù)。
所以，我們可以猜測，兩個goto fail語句，可能是因為對code在不同branch上做merge發(fā)生的。版本工具merge代碼的時候，經(jīng)常性的會出現(xiàn)這樣的問題。如果代碼的 diff很多，這個問題會很容易就沒有注意到。就算有code review，這個有問題的代碼也很難被找出來的。如果你來review下面的diff，你會注意到這個錯誤嗎？
也就是說，在重構分支上的代碼是對的，但是在分支merge的時候，被merge工具搞亂了。所以說，我們在做code merge的時候，一定要小心小心再小心，不能完全相信merge工具。
2）關于測試
很明顯，這個bug很難被code review發(fā)現(xiàn)。對于重構代碼和代碼merge里眾多的diff，是很難被review的。
當然，“事后諸葛亮”的人們總是很容易地說這個問題可以被測試發(fā)現(xiàn)，但是實際情況是這樣的嗎？
這個問題也很難被功能測試發(fā)現(xiàn)，因為這個函數(shù)在是在網(wǎng)絡握手里很深的地方，功能 測試不一定能覆蓋得那么深，你要寫這樣的case，必需對TLS的協(xié)議棧非常熟悉，熟悉到對他所有的參數(shù)都很熟悉，并能寫出針對每一個參數(shù)以及這些參數(shù)的 組合做一堆test case，這個事情也是一件很復雜的事。要寫出所有的case本身就是一件很難很難的事情。關于這個叫 SSLVerifySignedServerKeyExchange()函數(shù)的細節(jié)，你可以看看相關的ServerKeyExchange RFC文檔。
如果只看這個問題的話，你會說對這個函數(shù)做的 Unit Test 可以發(fā)現(xiàn)這個問題，是的。但是，別忘了SSL/TLS這么多年了，這些基礎函數(shù)都應該是很穩(wěn)定的了， 在事前，我們可能不會想到要去為這些穩(wěn)定了多少年的函數(shù)寫幾個Unit Test。
只要有足夠多的時間，我們是可以對所有的功能點，所有的函數(shù)都做UT，也可以去追求做代碼覆蓋和分支覆蓋一樣。但有一點我們卻永遠無法做到，那就是——窮舉所有的負面案例。所以，對于測試來說，我們不能走極端，需要更聰明的測試。就像我在《我們需要專職的QA》文章里的說過的——測試比coding難度大多了，測試這個工作只有高級的開發(fā)人員才做得好。我從來不相信不寫代碼的人能做好測試。
這里，我并不是說通過測試來發(fā)現(xiàn)這個問題的可能性不大，我想說的是，測試很重要，單測更重要。但是，我們無法面面俱到。在我們沒有關注到的地方，總會發(fā)生愚蠢的錯誤。
P.S.，在各大網(wǎng)站對這個事的討論中，我們可以看到OS X下的curl命令居然可以接受一個沒有驗證過的IP地址的https的請求，雖然現(xiàn)在還沒有人知道這事的原因，但是，這可能是沒有在測試中查到的一個原因。
3）關于編碼風格
對于程序員來說，在C語言中，省掉語句大括號是一件非常不明智 的事情。如我們強制使用語句塊括號，那么，這兩個goto fail都會在一個if的語句塊里，而且也容易維護并且易讀。（另外，通過這個bug，我們可以感受到，像Python那樣，用縮進來表示語句塊，的確是 挺好的一件事）
也有人說，如果你硬要用只有單條語句，且不用語句塊括號，那么，這就是一條語句，應該放在同一行上。如下所示：
- if (check_something) do_something();
但是這樣一來，你在單步調(diào)試代碼的時候，就有點不爽了，當你step over的時候，你完全不知道if的條件是真還是假。所以，還是分多行，加上大括號會好一些。
相似的問題，我很十多年前也犯過，而且那次我出的問題也比較大，導致了用戶的數(shù)據(jù)出錯。那次就是維護別人的代碼，別人的代碼就是沒有if的語句塊括號，就像蘋果的代碼那樣。我想在return z之前調(diào)用一個函數(shù)，結果就杯具了：
- if ( ...... )
- return x;
- if ( ...... )
- return y;
- if ( ...... )
- foo();
- return z;
這個錯誤一不小心就犯了，因為人的大腦會相當然地認為縮進的都是一個語句塊里的。但是如果原來的代碼都加上了大括號，然后把縮進做正常，那么對后面維護的人會是一個非常好的事情。就不會犯我這個低級錯誤了。就像下面的代碼一樣，雖然寫起來有點羅嗦，但利人利己。
- if ( ...... ){
- return x;
- }
- if ( ...... ){
- return y;
- }
- if ( ...... ){
- return z;
- }
與此類似的代碼風格還有如下，你覺得哪個更容易閱讀呢？
- if (!p) 和 if (p == NULL)
- if (p) 和 if (p != NULL)
- if (!bflag) 和 if (bflag == false)
- if ( CheckSomthing() ) 和 if ( CheckSomething() == true )
另外還有很多人在switch 語句里用case來做if，也就是說case后面沒有break。就像Duff’s Device一樣，再配以goto，代碼就寫得相當精彩了（這里有個例子）
所以說，代碼不是炫酷的地方是給別人讀的。
另外，我在想，為什么蘋果的這段代碼不寫成下面這樣的形式？你看，下面這種情況不也很干凈嗎？
- if ( (err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0 )
- || (err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
- || (err = SSLHashSHA1.update(&hashCtx, &serverRandom) != 0)
- || (err = SSLHashSHA1.update(&hashCtx, &signedParams) != 0)
- || (err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)) {
- goto fail;
- }
其實，還可以做一些代碼上的優(yōu)化，比如，把fail標簽里的那些東西寫成一個宏，這樣就可以去掉goto語句了。
4）關于goto語句
關于goto語句，1968年，Edsger Dijkstra 投了一篇文章到Communications of the ACM。原本的標題是《A Case Against the Goto Statement》。CACM編輯Niklaus Wirth靈感來了，把標題改為我們熟知的 《Go To Statement Considered Harmful》Dijkstra寫的內(nèi)容也是其一貫的犀利語氣，文中說：“幾年前我就觀察到，一個程序員的品質(zhì)是其程序中goto語句的密度成反比的”，他還說，“后來我發(fā)現(xiàn)了為什么goto語句的使用有這么嚴重的后果，并相信所有高級語言都應該把goto廢除掉。” （花絮：因為，這篇文章的出現(xiàn)，計算學界開始用’ X considered harmful ’當文章標題的風潮，直到有人終于受不了為止）
為什么goto語句不好呢？Dijkstra說，一個變量代表什么意義要看其上下文。一個程序用N記錄房間里的人數(shù)，在大部分時候，N代表的是“目前房間里的人”。但在觀察到又有一個人進房間后、把N遞增的指令前的這段程序區(qū)塊中，N的值代表的是“目前房間里的人數(shù)加一”。因此，要正確詮釋程序的狀態(tài)，必須知道程序執(zhí)行的歷史，或著說，知道現(xiàn)在“算到哪”了。
怎么談“算到哪了”？如果是一直線執(zhí)行下來的程序，我們只要指到那條語句，說“就是這里”，就可以了。如果是有循環(huán)程序，我們可能得說：“現(xiàn)在在循環(huán)的這個地方，循環(huán)已經(jīng)執(zhí)行了第i次”。如果是在函數(shù)中，我們可能得說：“現(xiàn)在執(zhí)行到函數(shù)p的這一點；p剛剛被q調(diào)用，調(diào)用點在一個循環(huán)中，這個循環(huán)已經(jīng)執(zhí)行了i次”。
如果有goto語句了呢？那就麻煩了。因為電腦在執(zhí)行某個指令前，可能是從程序中許許多多goto其中之一跳過來的。要談某變量的性質(zhì)也幾乎變得不可能了。這就是為什么goto語句問題。
Dijkstra的這篇文章對后面很多程序員有非常深的影響，包括我在內(nèi)，都覺得Goto語句能不用就不用，雖然，我在十年前的《編程修養(yǎng)》（這篇文章已經(jīng)嚴重過時，某些條目已經(jīng)漏洞百出）中的第23條也說過，我只認為在goto語句只有一種情況可以使用，就是蘋果這個bug里的用法。但是我也同意Dijkstra，goto語句能不用就不用了。就蘋果的這個問題而言，在更為高級的C++中，使用RAII技術，這樣的goto語句已經(jīng)沒有什么存在的意義了。
Dijkstra這篇文章后來成為結構化程式論戰(zhàn)最有名的文章之一。長達19年之后，F(xiàn)rank Rubin投了一篇文章到CACM,標題為《‘ Go To Considered Harmful’ Considered Harmful 》Rubin說，「雖然Dijkstra的說法既太學術又缺乏說服力」，卻似乎烙到每個程序員的心里了。這樣，當有人說“用goto語句來解這題可能會比較好”會被嚴重鄙視。于是Rubin出了一道這樣的題：令X為N * N的整數(shù)陣列。如果X的第i行全都是零，請輸出i。如果不只一行，輸出最小的i .
Rubin找了一些慣用goto和不用goto的程序員來解題，發(fā)現(xiàn)用goto的程序又快又清楚。而不用goto通常花了更多的時間，寫出很復雜的解答。你覺得呢？ 另外，你會怎么寫這題的程序呢？
（花絮：以后幾個月的CACM熱鬧死了。編輯收到許多回應，兩個月后刊出了其中五篇。文章也包括了《“‘GOTO Considered Harmful’ Considered Harmful” Considered Harmful? 》）
對于我而言，goto語句的弊遠遠大于利，在99%的情況下，我是站在反goto這邊的。Java和Python就沒有提供Goto語句，原因就是因為goto語句很容易被濫用！
（花絮：這段時間，我在開發(fā)Nginx的模塊，因為以前沒有做過，而且Nginx的開發(fā)文檔也不好，所以就得讀一些別人的源代碼。當我看了某個nginx redis的模塊里的這段代碼 ngx_http_redis2_reply.c 看到里面飛沙走石的goto語句，我崩潰了，當然，這是代碼自動生成工具生成出來的，只是想以這個例子說明goto也是混亂代碼的一種黑魔法（另，這位同學看似很喜歡goto語句，在很多代碼里都能看得見，比如：這里，這里，還有這里……，雖然我覺得很多goto都沒有必要）。我想說，如果人把代碼寫成這樣，那我看到這樣的代碼的時候，就像我在某個餐館看到了他那骯臟的廚房，無論做菜的技藝有多高超，做的菜做得有多好看多好吃，我都惡心得一點也不想吃了）
總結
你看，我們不能完全消滅問題，但是，我們可以用下面幾個手段來減少問題：
1）盡量在編譯上發(fā)生錯誤，而不是在運行時。
2）代碼是讓人讀的，順便讓機器運行。不要怕麻煩，好的代碼風格，易讀的代碼會減少很多問題。
3）Code Review是一件很嚴肅的事情，但 Code Reivew的前提條件是代碼的可讀性一定要很好。
4）測試是一件很重要也是很難的事情，尤其是開發(fā)人員要非常重視。
5）不要走飛線，用飛線來解決問題是可恥的！所以，用goto語句來組織代碼的時代過去了，你可以有很多種方式不用goto也可以把代碼組織得很好。
最后，我在淘寶過去的一年里，經(jīng)歷過一些P1/P2故障，尤其是去年的8-9月份故障頻發(fā)的月份，我發(fā)現(xiàn)其中有70%的P1/P2故障，就是因為沒 有code review，沒有做好測試，大量地用飛線來解決問題，歸根結底就是只重業(yè)務結果，對技術沒有應有的嚴謹?shù)膽B(tài)度和敬畏之心。
正如蘋果的這個“goto fail”事件所暗喻的，如果你對技術沒有應有的嚴謹和敬畏之心，你一定會——
Go To Fail !!!
原文鏈接：http://coolshell.cn/articles/11112.html
