Rust और C/C++ के बीच मेमोरी-सेफ्टी CVE कैसे अलग होते हैं

मूल लेख ↗ Hacker News चर्चा ↗

Rust की memory safety की C और C++ से तुलना वास्तविक CVEs, undefined behavior की खामियों, और प्रत्येक ecosystem में “unsafe” code तथा API misuse को कैसे संभाला जाता है, इसके आधार पर की गई है। टिप्पणीकार तर्क देते हैं कि Rust का borrow checker और safety culture vulnerabilities की कई श्रेणियों को वास्तविक रूप से घटाते हैं, जबकि आलोचक इसकी जटिलता, debug और release के बीच overflow व्यवहार की असंगति, और गहरे dependency trees से बढ़ते supply-chain risk को उजागर करते हैं। अन्य लोग जवाब देते हैं कि hardened libraries, sanitizers, और safer idioms के साथ “modern C++” सिद्धांततः बहुत अंतर भर सकता है, लेकिन यह भी नोट करते हैं कि बड़े वास्तविक C/C++ codebases अभी भी गंभीर memory bugs लेकर shipping करते हैं, जिसके कारण Android और Linux kernel जैसी projects में Rust अपनाया जा रहा है.

Rust, undefined behavior, और unsafe

  • कुछ लोग तर्क देते हैं कि Rust में UB आपके crate में सीधे unsafe का उपयोग किए बिना भी हो सकता है: no_std, भाषा की soundness की खामियों, dependencies या standard library में UB, या compiler/LLVM bugs के माध्यम से।
  • अन्य लोग Rust के मॉडल पर ज़ोर देते हैं: UB को कहीं न कहीं unsafe से ही उत्पन्न होना चाहिए (dependencies या std सहित); लाभ यह है कि unsafe स्थानीय होता है और उसकी समीक्षा की जा सकती है।

Integer overflow semantics

  • Rust के “debug में panic, release में wrap” व्यवहार पर विवाद।
  • आलोचक कहते हैं कि दो व्यवहार होने से overflow व्यावहारिक रूप से UB जितना ही अविश्वसनीय हो जाता है और वे चाहते हैं कि overflow हमेशा panic करे।
  • अन्य लोग ज़ोर देते हैं कि यह implementation-defined है, UB नहीं: व्यवहार सीमित और कॉन्फ़िगर करने योग्य है (overflow-checks = true), C/C++ UB के विपरीत जो अत्यधिक गलत optimizations तक ले जा सकता है।

Rust CVEs को कैसे समझें

  • Rust libraries आम तौर पर ऐसी किसी भी misuse को, जो UB पैदा कर सकती है, CVE मानते हैं, भले ही exploitation अवास्तविक हो।
  • C/C++ ecosystems ऐसे मुद्दों को शायद ही CVEs के रूप में वर्गीकृत करते हैं, इसलिए CVEs की raw “संख्या” को language safety के लिए भ्रामक मेट्रिक माना जाता है।
  • कुछ लोगों को चिंता है कि यह panics को DoS vulnerabilities की तरह मानने तक फैल सकता है; अन्य इसे उस संस्कृति का हिस्सा मानते हैं जो correctness को प्राथमिकता देती है।

मेमोरी-सेफ्टी बग्स की व्यापकता और महत्व

  • एक टिप्पणीकार का दावा है कि memory bugs “औसत” vulnerabilities का बहुत छोटा हिस्सा हैं; अन्य लोग इससे असहमत हैं और thread के भीतर दिए गए data का हवाला देते हैं कि memory safety issues high-impact zero-days पर हावी हैं।
  • इस पर बहस है कि broad codebases को Rust में port करना over-optimization है या उच्च-मूल्य, भारी हमले वाले software (browsers, OS components, Android) के लिए उचित।

Rust बनाम आधुनिक C++ safety strategies

  • एक पक्ष का तर्क है कि modern C++ के साथ hardened libraries, sanitizers, और guidelines memory bugs को काफी हद तक हल कर सकते हैं, यदि उन्हें consistently इस्तेमाल किया जाए।
  • जवाब में:
    • व्यवहार में कई बड़े C/C++ codebases अभी भी unsafe रहते हैं (Android, Chromium, system libraries)।
    • Rust में safety default है; C++ में safety अक्सर opt-in, सावधानीपूर्ण discipline, और ऐसे toolchains की मांग करती है जिन्हें teams delivery pressure में अक्सर ढीला कर देती हैं।
    • वास्तविक दुनिया की रिपोर्टें (जैसे Android) legacy C/C++ code की तुलना में Rust से memory vulnerabilities में बड़े reduction का प्रमाण बताई जाती हैं।

Nulls, assertions, और contracts

  • curl_getenv जैसी functions और null inputs पर assert करना चाहिए या नहीं, इस पर चर्चा।
  • कुछ लोग व्यापक precondition checks का समर्थन करते हैं; अन्य कहते हैं कि C में यह noisy हो जाता है और अक्सर “null deref पर वैसे भी crash” तक सिमट जाता है।
  • Rust के Option<T> और non-nullable references के साथ तुलना की जाती है: APIs को स्पष्ट रूप से None को स्वीकार करना पड़ता है, और misuse से UB के बजाय साफ़ backtraces के साथ panics होते हैं।

Performance और adoption trends

  • Ladybird के HTML parser rewrite जैसे उदाहरण दिखाते हैं कि Rust, C++ को समान या बेहतर performance के साथ बदल सकता है।
  • बहस यह है कि speed gains Rust से आते हैं या rewrites के दौरान redesign के अवसरों से।
  • C और C++ कुछ domains (browsers, kernels) में पीछे होते दिख रहे हैं, हालांकि कई domains (HPC, HFT, standards-driven stacks) अभी भी C/C++ के इर्द-गिर्द ही घूमते हैं।

Rust की complexity और dependency concerns

  • आलोचक Rust की वैचारिक जटिलता (ownership, lifetimes, advanced types) और borrow checker को संतुष्ट करने के लिए types को ढालने में लगने वाले प्रयास को रेखांकित करते हैं।
  • समर्थक इसे complexity को छिपाने के बजाय “स्पष्ट” करने के रूप में देखते हैं, जिससे code अधिक सुरक्षित और अधिक debuggable बनता है।
  • Rust में बड़े, गहरे dependency trees (पतली stdlib, कई crates, build.rs, GitHub-निर्भर publishing) और उससे जुड़ा supply-chain risk लेकर व्यापक चिंता है।
  • बचाव में कहा जाता है कि C/C++ अक्सर code vendoring या copy-pasting से इस समस्या को “हल” करते हैं, जिससे dependencies समाप्त नहीं होतीं बल्कि छिप जाती हैं।