Rowhammer हमलों के प्रति sudo को कम संवेदनशील बनाने की कोशिश करें
`sudo` codebase में हाल का एक बदलाव critical authorization states को Rowhammer-style DRAM attacks के जरिए flip करना कठिन बनाने के लिए बड़े Hamming distances वाले विशेष numeric constants पेश करता है। टिप्पणीकार इस बात पर चर्चा करते हैं कि क्या ऐसी software-level hardening सार्थक है, जबकि Rowhammer मूलतः hardware reliability की समस्या है; वे complexity, performance, और वास्तविक threat models के trade-offs पर बहस करते हैं, और compiler support, ECC memory, तथा बेहतर hardware specifications जैसे विकल्प सुझाते हैं। यह चर्चा secure और resilient system design के व्यापक निहितार्थों को भी छूती है, high-reliability embedded systems से लेकर shared hosting और cloud environments तक.
पैच और कोडिंग तकनीक
- sudo अब auth states (SUCCESS, FAILURE, ERROR, आदि) के लिए विशेष रूप से चुने गए 32-बिट constants का उपयोग करता है, जिनके बीच Hamming distances बड़े हैं।
- लक्ष्य: Rowhammer को “deny” को “allow” में बदलने के लिए कई विशिष्ट bit flips की आवश्यकता हो, जिससे प्रदर्शित Mayhem/Rowhammer exploit की व्यवहार्यता कम हो।
- कुछ commenters को यह defensive coding शैली दिलचस्प लगती है, लेकिन चिंता है कि इसे व्यापक रूप से लागू करना “hell” होगा; अन्य लोग इसे लंबे समय से ज्ञात fault-tolerance विचारों (single-event upsets, voting, ECC) से मिलता-जुलता मानते हैं।
भाषा / compiler विचार
- कई लोग compiler support का सुझाव देते हैं: “secure” enums के लिए attributes, जिनके encodings Hamming distance को अधिकतम करें, या hardening modes जो optimization के दौरान “redundant” checks को हटाने के बजाय बनाए रखें।
- C/C++ enums ABI/backwards compatibility के कारण tricky हैं; Rust और dynamic languages में ऐसी सुविधाएँ अधिक आसानी से समर्थित हो सकती हैं।
- GCC के
hardboolको booleans के लिए एक समान विचार के रूप में उद्धृत किया गया है। - अन्य लोग high-distance codes generate करने के algorithms पर चर्चा करते हैं; कुछ बताते हैं कि sudo द्वारा चुने गए values mathematically optimal नहीं हैं, और optimal codes बनाना coding-theory की एक गैर-तुच्छ समस्या है।
प्रभावशीलता और trade-offs
- समर्थक इसे defense-in-depth के रूप में पेश करते हैं: यह सीधे एक ज्ञात Rowhammer path को रोकता है और setuid binaries जैसे high-value targets के लिए उपयुक्त है।
- skeptics का तर्क है कि यह केवल एक variable class की रक्षा करता है, अन्य corruptible control/data को संबोधित नहीं करता, और code को पढ़ना तथा audit करना कठिन बनाता है।
- कुछ लोग नोट करते हैं कि यदि attacker के पास पहले से local code execution है, तो escalation के आसान रास्ते हो सकते हैं; हालांकि अन्य counter करते हैं कि shared hosting, clusters, और game servers अभी भी hardening से लाभ उठा सकते हैं।
Rowhammer, ECC, और hardware बनाम software
- कई टिप्पणियाँ जोर देती हैं कि Rowhammer मूल रूप से DRAM/physics की समस्या है। बहस इस पर विभाजित है:
- “इसे hardware में ठीक करें / खराब RAM वापस करें” बनाम
- “Physics और density के कारण पूर्ण immunity अवास्तविक है; software को मदद करनी होगी।”
- ECC और on-die ECC Rowhammer risk को कम करते हैं लेकिन समाप्त नहीं करते; sophisticated attacks और multi-bit flips correction को bypass कर सकते हैं, हालांकि ECC को कम से कम alerts trigger करने चाहिए।
- बताया गया है कि modern DRAM density बढ़ने के साथ अधिक vulnerable हो रही है; vendor-side mitigations जैसे targeted refresh मौजूद हैं, लेकिन वे स्वयं imperfect हो सकती हैं या दुरुपयोग के लिए खुली हो सकती हैं।
व्यापक प्रभाव
- यही pattern (max-distance encodings, sanity checks) microcontrollers और high-radiation environments के लिए भी सुझाया गया है, ताकि invalid control paths detect हों और watchdog resets trigger हों।