Cve-rs: सुरक्षित Rust में लिखी गई तेज़ मेमोरी कमजोरियाँ

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

cve-rs नाम का एक proof-of-concept Rust crate, Rust की lifetime और variance system में मौजूद लंबे समय से चली आ रही compiler soundness bug का उपयोग करके ऐसे code में memory-safety violations पैदा करता है जिसमें कोई `unsafe` block नहीं है। टिप्पणीकार समझाते हैं कि implied lifetime bounds, function pointer variance, और मौजूदा trait solver कैसे मिलकर इस edge case को संभव बनाते हैं, और बताते हैं कि Miri इस समस्या को detect कर सकता है, भले ही rustc code को स्वीकार कर ले। यह चर्चा इस बात पर विचार करती है कि ऐसे bugs कितने दुर्लभ और contrived हैं, बनाम Rust की “memory-safe” भाषा के रूप में marketing, और क्या ऐसे unsound corner cases व्यवहार में उस गारंटी को वास्तव में कमजोर करते हैं।

Rust lifetime syntax और मूल बग

  • चर्चा इस बात पर केंद्रित है कि &'a &'b T , explicit where 'b: 'a bound जोड़ने से कैसे अलग है।
  • कई टिप्पणियाँ समझाती हैं: nested references implied lifetime bounds बनाते हैं, जिन्हें compiler को मानना चाहिए; outer lifetime को inner से अधिक नहीं चलना चाहिए।
  • बग तब उत्पन्न होता है जब ये implied bounds function pointer variance और higher-ranked lifetimes के साथ interact करते हैं: compiler कुछ casts के बाद गलत तरीके से मान सकता है कि एक lifetime दूसरी से अधिक चलती है, जिससे “safe” code में use-after-free संभव हो जाता है।
  • कुछ लोग ज़ोर देते हैं कि यह late-bound बनाम early-bound lifetimes और function types के लिए variance (contra-/covariance) के handling से जुड़ा है।

Miri, Polonius, और trait solver का काम

  • Miri (एक interpreter/sanitizer) runtime पर इस unsoundness को detect करता है, भले ही Rust code syntactically “safe” हो।
  • इस पर बहस है कि proper fix के लिए नया trait solver और संबंधित refactors (implied bounds, coinduction) पूर्व-शर्त हैं या नहीं; links बताते हैं कि यह bug स्पष्ट रूप से उस काम पर blocked है।
  • कुछ लोग “new solver इसे ठीक कर देगा” वाली कथाओं को लेकर skeptical हैं, लेकिन अन्य लोग नोट करते हैं कि एक साफ तकनीकी योजना मौजूद है, बस कठिन और धीमी है।

Safety guarantees, unsoundness, और marketing

  • एक पक्ष का तर्क है: 80+ खुले “unsound” issues होने पर भी, Rust C/C++ से कहीं अधिक सुरक्षित है, और ये दुर्लभ edge cases हैं, जिन्हें गलती से hit करना अक्सर कठिन होता है।
  • दूसरे कहते हैं: कोई भी unsoundness “memory safety” के दावों को कमजोर करती है; ऐसे bugs ठीक होने तक Rust को “memory safer” कहा जाना चाहिए।
  • इस पर चर्चा होती है कि यह compiler bug है या type theory की कोई गहरी flaw; कुछ लोग insist करते हैं कि design sound बनाया जा सकता है, लेकिन implementation पीछे है।

Ergonomics और learnability

  • कुछ पाठकों को bug-triggering code डरावना या unreadable लगता है और चिंता होती है कि Rust बहुत “symbol heavy” है और RSI-inducing है।
  • दूसरे जवाब देते हैं कि यह obfuscated, minimal-repro शैली का code है, सामान्य Rust का प्रतिनिधि नहीं, और अधिकांश वास्तविक code में बहुत कम explicit lifetimes होती हैं।
  • Lifetimes को अनौपचारिक रूप से “memory pools” with labels की तरह समझाया जाता है, जिसे कई लोग स्पष्ट करने वाला मानते हैं।
  • Rust syntax choices की व्यापक आलोचना और बचाव दोनों हैं, और कुछ unsafe-related syntax तथा function syntax को बेहतर ढंग से डिज़ाइन किया जा सकता था, ऐसे सुझाव भी दिए जाते हैं।

Practical impact और exploitability

  • कई लोग ज़ोर देते हैं कि इसका exploit करना contrived code और anti-optimization tricks मांगता है; यह गलती से लिखे जाने की संभावना कम है।
  • फिर भी, टिप्पणीकार नोट करते हैं कि ऐसा एक भी hole इस अपेक्षा के विरुद्ध है कि safe Rust code memory corruption नहीं कर सकता, और इसे गंभीरता से लिया जाना चाहिए।
  • /proc/self/mem जैसे अन्य रास्तों से तुलना की जाती है, और याद दिलाया जाता है कि Rust की guarantees केवल उस पर लागू होती हैं जो program स्वयं करता है, external processes या OS पर नहीं।

Miscellaneous

  • प्रोजेक्ट के मज़ाकिया license (GLWTS) और download_more_ram() function को humorous touches के रूप में नोट किया गया है।
  • कोई shell prompt के बारे में पूछता है; दूसरे इसे एक लोकप्रिय prompt tool के रूप में पहचानते हैं।