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