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

以下為譯文：

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

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

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

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

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

我想說的第一個例子最初是Kostya Serebryany提出的（https://github.com/isocpp/CppCoreGuidelines/issues/1038），這個例子可以說明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"分配了一個新的std::string，然后將其轉換成std::string_view。此時臨時的std::string被釋放，但sv依然指向它原來擁有的內存。任何對sv的訪問都會造成“釋放后使用”的漏洞。

天??！C++的編譯器無法檢測到sv擁有某個引用，而該引用的壽命比被引用的對象還要長的情況。同樣的問題也會影響std::span，它也是個非?，F代的C++類型。

另一個有意思的例子是使用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超出了作用域，從而銷毀了指向數據的最后一個引用，導致數據被釋放。此時y就成了懸空指針。即使我們謹慎地使用智能指針也無法避免這個問題。沒錯，人們的確會編寫代碼來處理std::shared_ptr<T>&，作用之一就是設法避免引用計數無謂的增加或減少。

std::optional<T>解引用

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

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

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

#include <optional>

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

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

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

#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ù)內存的引用以及長度值。這樣針對多種不同類型進行編程就很容易：std::span<uint8_t>可以指向std::vector<uint8_t>、std::array<uint8_t, N>擁有的內存，甚至可以指向原始指針擁有的內存。不檢查邊界就會導致安全漏洞，而許多情況下，span能幫你確保長度是正確的。

與其他STL數據結構一樣，span的operator[]方法并不會進行任何邊界檢查。這是可以理解的，因為operator[]是最常用的方法，也是訪問數據結構的默認方法。而至少從理論上，std::vector和std::array可以安全地使用，因為它們提供了at()方法，該方法會進行邊界檢查（在實踐中我從來沒見人用過這個方法，不過可以想象一個項目，通過靜態(tài)分析工具來禁止調用std::vector<T>::operator[]）。span不提供at()方法，也不提供任何進行邊界檢查的方法。

有趣的是，Firefox和Chromium移植的std::span都會在operator[]中進行邊界檢查，所以這兩個項目也無法安全地移植到std::span上。

結論

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

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

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

作者：Alex Gaynor

編譯：CSDN-彎月

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