經(jīng)常有程序員為C++辯護(hù)說：“只要你不使用任何從C繼承過來的功能，C++就是安全的”！但事實(shí)非如此。根據(jù)本文作者在大型C++項(xiàng)目上（遵從現(xiàn)代的慣用做法）的經(jīng)驗(yàn)來看，C++提供的類型完全不能阻止漏洞的泛濫。本文中就會(huì)給出一些完全根據(jù)現(xiàn)代C++的慣用做法編寫的代碼，你會(huì)發(fā)現(xiàn)這些代碼仍然會(huì)引發(fā)漏洞。

以下為譯文：

我經(jīng)常批評(píng)內(nèi)存不安全的語言，主要是C和C++，以及它們引發(fā)的大量安全漏洞。根據(jù)大量使用C和C++的軟件項(xiàng)目的審查結(jié)果，我得出了一個(gè)結(jié)論：軟件行業(yè)應(yīng)該使用內(nèi)存安全的語言（例如Rust和Swift）。

人們常常在回復(fù)我時(shí)說，這個(gè)問題并不是C和C++本身的問題，而是使用這兩種語言的開發(fā)者的錯(cuò)。

具體來說，我經(jīng)常聽到人們?yōu)镃++辯護(hù)說：“只要你不使用任何從C繼承過來的功能，C++就是安全的”（我理解這句話指的是原始指針、數(shù)組作為指針使用、手動(dòng)malloc/free以及其他類似功能。但我認(rèn)為有一點(diǎn)值得注意，由于C的特性明確地融入了C++，那么在實(shí)踐中，大部分C++代碼都需要處理類似的情況。），或者類似的話，比如只要遵從現(xiàn)代C++的類型和慣用做法，就不會(huì)引發(fā)內(nèi)存方面的漏洞。

我很感謝C++的智能指針類型，因?yàn)檫@種類型的確非常有用。不幸的是，根據(jù)我在大型C++項(xiàng)目上（遵從現(xiàn)代的慣用做法）的經(jīng)驗(yàn)來看，光靠這些類型完全不能阻止漏洞的泛濫。我會(huì)在本文中給出一些完全根據(jù)現(xiàn)代C++的慣用做法編寫的代碼，你會(huì)發(fā)現(xiàn)這些代碼仍然會(huì)引發(fā)漏洞。

掩蓋“釋放后使用”的引用

我想說的第一個(gè)例子最初是Kostya Serebryany提出的（https://github.com/isocpp/CppCoreGuidelines/issues/1038），這個(gè)例子可以說明C++的std::string_view能夠很容易地掩蓋“釋放后使用”的漏洞：

#include <iostream>
#include <string>
#include <string_view>

int main() {
  std::string s = "Hellooooooooooooooo ";
  std::string_view sv = s + "World\n";
  std::cout << sv;
}

在這段代碼中，s + "World\n"分配了一個(gè)新的std::string，然后將其轉(zhuǎn)換成std::string_view。此時(shí)臨時(shí)的std::string被釋放，但sv依然指向它原來擁有的內(nèi)存。任何對(duì)sv的訪問都會(huì)造成“釋放后使用”的漏洞。

天啊！C++的編譯器無法檢測(cè)到sv擁有某個(gè)引用，而該引用的壽命比被引用的對(duì)象還要長(zhǎng)的情況。同樣的問題也會(huì)影響std::span，它也是個(gè)非?，F(xiàn)代的C++類型。

另一個(gè)有意思的例子是使用C++的lambda功能來掩蓋引用：

#include <memory>
#include <iostream>
#include <functional>


std::function<int(void)> f(std::shared_ptr<int> x) {
    return [&]() { return *x; };
}

int main() {
    std::function<int(void)> y(nullptr);
    {
        std::shared_ptr<int> x(std::make_shared<int>(4));
        y = f(x);
    }
    std::cout << y() << std::endl;
}

上述代碼中，f中的[&]表明lambda用引用的方式來捕獲值。然后在main中，x超出了作用域，從而銷毀了指向數(shù)據(jù)的最后一個(gè)引用，導(dǎo)致數(shù)據(jù)被釋放。此時(shí)y就成了懸空指針。即使我們謹(jǐn)慎地使用智能指針也無法避免這個(gè)問題。沒錯(cuò)，人們的確會(huì)編寫代碼來處理std::shared_ptr<T>&，作用之一就是設(shè)法避免引用計(jì)數(shù)無謂的增加或減少。

std::optional<T>解引用

std::optional表示一個(gè)可能存在也可能不存在的值，通常用來替換哨兵值（如-1或nullptr）。它提供的一些方法，如value()，能夠提取出它包含的T，并在optional為空的時(shí)候拋出異常。但是，它也定義了operator*和operator->。

這兩個(gè)方法能訪問底層的T，但它們并不會(huì)檢查optional是否包含值。

例如，下面的代碼就會(huì)返回未初始化的值：

#include <optional>

int f() {
    std::optional<int> x(std::nullopt);
    return *x;
}

如果用std::optional來代替nullptr，就會(huì)產(chǎn)生更加嚴(yán)重的問題！對(duì)nullptr進(jìn)行解引用會(huì)產(chǎn)生段錯(cuò)誤（這并不是安全漏洞，只要不是在舊的內(nèi)核上）。而對(duì)nullopt進(jìn)行解引用會(huì)產(chǎn)生未初始化的值作為指針，這會(huì)導(dǎo)致嚴(yán)重的安全問題。盡管T*也可能擁有未經(jīng)初始化的值，但是這種情況非常罕見，遠(yuǎn)遠(yuǎn)不如對(duì)正確地初始化成nullptr的指針進(jìn)行解引用的操作。

而且，這個(gè)問題并不需要使用原始的指針。即使使用智能指針也能得到未初始化的野指針：

#include <optional>
#include <memory>

std::unique_ptr<int> f() {
    std::optional<std::unique_ptr<int>> x(std::nullopt);
    return std::move(*x);
}

std::span<T>索引

std::span<T>能讓我們方便地傳遞指向一片連續(xù)內(nèi)存的引用以及長(zhǎng)度值。這樣針對(duì)多種不同類型進(jìn)行編程就很容易：std::span<uint8_t>可以指向std::vector<uint8_t>、std::array<uint8_t, N>擁有的內(nèi)存，甚至可以指向原始指針擁有的內(nèi)存。不檢查邊界就會(huì)導(dǎo)致安全漏洞，而許多情況下，span能幫你確保長(zhǎng)度是正確的。

與其他STL數(shù)據(jù)結(jié)構(gòu)一樣，span的operator[]方法并不會(huì)進(jìn)行任何邊界檢查。這是可以理解的，因?yàn)閛perator[]是最常用的方法，也是訪問數(shù)據(jù)結(jié)構(gòu)的默認(rèn)方法。而至少從理論上，std::vector和std::array可以安全地使用，因?yàn)樗鼈兲峁┝薬t()方法，該方法會(huì)進(jìn)行邊界檢查（在實(shí)踐中我從來沒見人用過這個(gè)方法，不過可以想象一個(gè)項(xiàng)目，通過靜態(tài)分析工具來禁止調(diào)用std::vector<T>::operator[]）。span不提供at()方法，也不提供任何進(jìn)行邊界檢查的方法。

有趣的是，F(xiàn)irefox和Chromium移植的std::span都會(huì)在operator[]中進(jìn)行邊界檢查，所以這兩個(gè)項(xiàng)目也無法安全地移植到std::span上。

結(jié)論

現(xiàn)代C++的慣用做法帶來了許多改變，能夠改善安全性：智能指針能更好地表示預(yù)想的生命周期，std::span能保證永遠(yuǎn)有正確的長(zhǎng)度，std::variant為union提供了安全的抽象。但是，現(xiàn)代C++也引入了一些新的漏洞禍根：lambda捕獲導(dǎo)致的釋放后使用，未初始化的optional，以及沒有邊界檢查的span。

以我編寫比較現(xiàn)代的C++的經(jīng)驗(yàn)，以及審查Rust代碼（包括使用了大量unsafe的Rust代碼）的經(jīng)驗(yàn)來看，現(xiàn)代C++的安全性完全比不上那些保證內(nèi)存安全的語言，如Rust、Swift（或者Python和JavaScript，盡管我很少見到能夠合理地用Python或C++編寫的程序）。

不可否認(rèn)，將現(xiàn)有的C和C++代碼移植到其他語言依然是個(gè)難題。但無論如何，問題應(yīng)該是我們應(yīng)該怎樣做，而不是我們是否應(yīng)該做。事實(shí)證明，即使最現(xiàn)代的C++慣用做法，也不可能保證C++的正確性。

作者：Alex Gaynor

編譯：CSDN-彎月

來源：https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/