現代 C++ 救不了程序員！

經常有程序員為C++辯護說：「只要你不使用任何從C繼承過來的功能，C++就是安全的」！但事實非如此。

根據本文作者在大型C++項目上（遵從現代的慣用做法）的經驗來看，C++提供的類型完全不能阻止漏洞的泛濫。本文中就會給出一些完全根據現代C++的慣用做法編寫的代碼，你會發現這些代碼仍然會引發漏洞。

打開今日頭條，查看更多圖片

作者 | Alex Gaynor

譯者 | 彎月

責編 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下為譯文：

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

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

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

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

掩蓋「釋放後使用」的引用

我想說的第一個例子最初是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
";
std::cout << sv;
}

在這段代碼中，s + "World
"分配了一個新的std::string，然後將其轉換成std::string_view。此時臨時的std::string被釋放，但sv依然指向它原來擁有的內存。任何對sv的訪問都會造成「釋放後使用」的漏洞。

天啊！C++的編譯器無法檢測到sv擁有某個引用，而該引用的壽命比被引用的對象還要長的情況。同樣的問題也會影響std::span，它也是個非常現代的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>能讓我們方便地傳遞指向一片連續內存的引用以及長度值。這樣針對多種不同類型進行編程就很容易：std::span<uint8_t>可以指向std::vector<uint8_t>、std::array<uint8_t, N>擁有的內存，甚至可以指向原始指針擁有的內存。不檢查邊界就會導致安全漏洞，而許多情況下，span能幫你確保長度是正確的。

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

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

作者：Alex Gaynor，在創業公司Alloy工作，之前從事過Firefox安全方面的工作。

本文由CSDN翻譯，轉載請註明來源出處。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！