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