...format和fmt库根本就格式串不安全。和log4j核爆级安全漏洞本质...

发布网友 发布时间：2024-10-01 18:53

我来回答

共1个回答

热心网友 时间：2024-10-17 13:42

C++20的format库与fmt库的安全隐患与log4j漏洞本质相同，因为它们都存在格式串不安全的问题。fmt库本身的设计缺陷和历史遗留问题导致了这一问题的显现。

实验表明，用户输入恶意格式化字符串，如连续的{0:2147483647}，在Linux上可能导致进程被意外终止，甚至引发段错误。C++23虽限制运行时格式串，但用户仍可通过其他途径如vformat等操作，加上宏和构建系统，使格式串可控。格式串的复杂实现使得内存安全漏洞难以检测，历史上类似问题层出不穷，如OpenSSL和glibc的修复工作持续不断。

性能上，std::format的性能极差，与纯静态库如fast_io相比，速度差距明显。fmt作者吹嘘的小体积实则是浮点处理等低效实现的表面现象。fast_io则完全没有格式串，提供了更安全的解决方案。

尽管有人认为格式串有助于本地化，但其潜在攻击风险过大。fast_io通过unsafe_rt_fprint提供了本地化支持，但强调了其仅限于设计目的，而非程序员广泛使用。总的来说，格式串不仅存在安全隐患，性能问题也限制了其在C++中的适用性，而C++的iostream已足够满足大部分需求。

因此，无论是std::format还是fmt，由于其设计上的问题，都不如iostream安全且高效。fast_io通过避免格式串，提供了一种更安全的编程选择。

热心网友 时间：2024-10-17 13:37

C++20的format库与fmt库的安全隐患与log4j漏洞本质相同，因为它们都存在格式串不安全的问题。fmt库本身的设计缺陷和历史遗留问题导致了这一问题的显现。

实验表明，用户输入恶意格式化字符串，如连续的{0:2147483647}，在Linux上可能导致进程被意外终止，甚至引发段错误。C++23虽限制运行时格式串，但用户仍可通过其他途径如vformat等操作，加上宏和构建系统，使格式串可控。格式串的复杂实现使得内存安全漏洞难以检测，历史上类似问题层出不穷，如OpenSSL和glibc的修复工作持续不断。

性能上，std::format的性能极差，与纯静态库如fast_io相比，速度差距明显。fmt作者吹嘘的小体积实则是浮点处理等低效实现的表面现象。fast_io则完全没有格式串，提供了更安全的解决方案。

尽管有人认为格式串有助于本地化，但其潜在攻击风险过大。fast_io通过unsafe_rt_fprint提供了本地化支持，但强调了其仅限于设计目的，而非程序员广泛使用。总的来说，格式串不仅存在安全隐患，性能问题也限制了其在C++中的适用性，而C++的iostream已足够满足大部分需求。

因此，无论是std::format还是fmt，由于其设计上的问题，都不如iostream安全且高效。fast_io通过避免格式串，提供了一种更安全的编程选择。