建站
咨詢
售后
建站咨詢
新聞中心
在前幾天看到 CVE-2014-6277 這個 BASH 的 bug 的時候，我就覺得挺奇葩的：這這種明顯是有意實現(xiàn)的功能怎么會存在這么大的安全隱患呢？我不是專門搞安全的，同時覺得，這個 bug 可能雖然影響廣泛，但并不是什么很有技術(shù)含量的利用思路。所以我就把這個事情放下沒去想它。然而，隨之而來的國內(nèi)國外的各種媒體宣傳、安全專家的聯(lián)名建議、茶余飯后的坊間暢談……對于 BASH 的這個 bug 無人不認為是個大 bug。不少人為此還在幸災(zāi)樂禍……但是我卻沒從各種評論中找到我的問題的答案。
創(chuàng)新互聯(lián)公司是一家專注于成都做網(wǎng)站、網(wǎng)站制作與策劃設(shè)計,崗巴網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)公司做網(wǎng)站,專注于網(wǎng)站建設(shè)10年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:崗巴等地區(qū)。崗巴做網(wǎng)站價格咨詢:13518219792
但是，當我看到這篇隨筆時，我不得不贊同作者的觀點：這根本不是 BASH 的 bug！
所以我將原文翻譯至此，希望能夠帶來一些思考。
也許我們今天看到的一個愚蠢的 bug，在歷史上的某一天，是一個有意而為之的神奇特性。也許我們應(yīng)該思考的不僅僅是這一刻的 bug 或者安全隱患本身，而是在軟件項目這個***工程和創(chuàng)作品雙重特性的活動中，如何有效的保證某個特性不會變成 bug。所以什么規(guī)范了，文檔了，可真得不是紙上談兵！
不過話說回來，無論如何，我仍然堅信：“Less is exponentially more!（大道至簡）”少一點 Feature 或許就是少一點 Bug 呢？
————翻譯分隔線————
我想要討論一下，關(guān)于這個 BASH 的安全問題其實不是一個 bug。這顯然是一個特性。誠然，這是一個被錯誤實現(xiàn)并被錯誤使用的特性。不過它仍然是個特性。
問題在于它是在 25 年前設(shè)計的。Apache 在那五年之后才出現(xiàn)！沒錯，那個時候互聯(lián)網(wǎng)已經(jīng)有了，不過那是個親密無間的小圈子。在那時，互聯(lián)網(wǎng)軟件和協(xié)議的安全根本不在考慮之列，更不用說開發(fā)像 shell 這樣的程序的時候了。
因此，我們討論的上下文是設(shè)計一個 UNIX shell，其子進程用非正式且常見的方式創(chuàng)建和運行。當創(chuàng)建一個新的子進程，環(huán)境變量可以用于從父進程向子進程傳遞某些數(shù)據(jù)。在 BASH 的情況里，這是一個需求提到的特性，在 BASH 父進程中定義的函數(shù)可以傳遞給子進程并獲得定義。使用環(huán)境變量傳遞這些函數(shù)的定義是自然而然的事情。
而在環(huán)境變量傳遞的函數(shù)定義之后可以執(zhí)行任何命令，就是那個略微超出設(shè)計規(guī)格的實現(xiàn)了。由于大部分情況下 BASH 程序在環(huán)境變量中存放的是要傳遞的函數(shù)，所以通常不會有其他命令。
不過在 BASH 被設(shè)計的時候，一個用戶是否能添加命令到這樣的環(huán)境變量中，會被認為是一個特性。在任何情況下，子進程的行為依賴于配置這個環(huán)境變量的用戶，所以沒有任何關(guān)于安全方面的擔憂。
這個特性被記錄在用于導(dǎo)出內(nèi)建命令的 -f 選項中。而使用內(nèi)容以“() {”開始的環(huán)境變量在函數(shù)定義后可以包含更多的命令的實現(xiàn)細節(jié)并沒有文檔記錄，不過仍然可以認為是一個特性。
問題在于，五年后，新的使用 BASH 作為子進程，并仍然使用環(huán)境變量傳遞數(shù)據(jù)的軟件被開發(fā)出來（Apache，DHCP 等等）。不幸的是，一些數(shù)據(jù)不再是來自可信的本地系統(tǒng)用戶（譯注：典型的物理安全信任），而是來自這個星球上的，互聯(lián)網(wǎng)上任意的用戶或者程序。同時，沒有文檔記錄的（但已經(jīng)被發(fā)布的）BASH 的特性卻被遺忘了。
這是一個關(guān)于 UNIX 系統(tǒng)的古老觀念，環(huán)境變量可以由父進程控制，還有更古老、更通用的觀念是輸入的數(shù)據(jù)應(yīng)當是合法的。
大概像 Apache 這樣的程序都對環(huán)境變量進行了正確的過濾。但不幸的是，它們在正確校驗輸入的數(shù)據(jù)時失敗了，因為它們并未考慮到以“() {” 開始的數(shù)據(jù)，將會被它們產(chǎn)生的 BASH 子進程解釋。如果這里有 bug 的話，也不是在 BASH 中，而是在 Apache 以及其他面向網(wǎng)絡(luò)的程序，沒有正確的驗證和控制它們傳遞給 BASH 的數(shù)據(jù)。
也就是說，BASH 有自己的問題，只不過跟大多數(shù)軟件一樣：它缺少一個規(guī)范的文檔，并且擁有沒有記錄的特性。
我們的問題不在于 BASH bug，這基本上與 Ariane 5 的 bug 類似：使用來自早期的系統(tǒng)中，規(guī)范已經(jīng)過期的模塊。
在該特定情況中，使用過期的規(guī)范的原因似乎是由于沒有任何規(guī)范被記錄下來，并且對于相關(guān)的實現(xiàn)細節(jié)也沒有文檔。但從另一方面來說，這是自由軟件，因此查閱源代碼的難度就跟在臉上找鼻子一樣容易。當復(fù)用一個沒有規(guī)范和文檔的模塊時，檢查源代碼的實現(xiàn)應(yīng)當是一個標準流程，不過顯然 Apache 或 DHCP 的開發(fā)者沒有這么做。
bug 還在那里，就像 Ariane 5 的 bug 不是 Ariane 4 的 bug 一樣！
原文出自：http://mikespook.com/2014/09/not-a-bash-bug/
分享標題：這根本不是BASH的BUG，是特征！
新聞來源：http://m.fisionsoft.com.cn/article/cdhpigs.html
