OpenBSD – सभी सिस्टम कॉल्स को पिन करना

नई syscall पिनिंग का दायरा

• कर्नेल अब syscalls को और सख्ती से सीमित करता है:
  • पहले: syscalls केवल प्रक्रियाओं के libc text region से ही अनुमति थे।
  • अब: इन्हें विशिष्ट libc syscall stubs तक पिन किया गया है।
  • static binaries के लिए: केवल वे syscalls अनुमति हैं जिनका वास्तव में binary में संदर्भ है; बाकी प्रभावी रूप से निष्क्रिय हैं।
• Program .text अब सीधे syscalls execute नहीं कर सकता; उन्हें libc के माध्यम से जाना होगा (या startup के दौरान ld.so के माध्यम से)।
• भाषा runtimes आम तौर पर libc को call करते हैं, इसलिए वे उपयोग योग्य रहते हैं; “weirdo” runtimes या JITs जो runtime पर raw syscalls synthesize करते हैं, ब्लॉक हो सकते हैं।

---

सुरक्षा प्रभाव और exploit तकनीकें

• Pinning कुछ ROP/JOP स्वतंत्रता कम करता है:
  • अब आप किसी भी reachable syscall instruction को arbitrary syscall में नहीं बदल सकते; केवल रिकॉर्ड किया गया syscall number ही अनुमति है।
  • फिर भी आप अनुमति-प्राप्त syscall के arguments का दुरुपयोग कर सकते हैं (उदा., यदि program सामान्यतः execve करता है, तो उसे अभी भी call किया जा सकता है)।
• Static binaries के लिए, attackers उन syscalls में ROP नहीं कर सकते जिन्हें program ने कभी उपयोग ही नहीं किया (उदा., यदि execve absent है), जिसे उपयोगी containment माना गया है।
• JITs अभी भी allowed syscall thunks में jump कर सकते हैं; browser JavaScript आम तौर पर वैसे भी सीधे syscall नहीं करता।
• एक और mitigation प्रभाव: syscalls को libc तक सीमित करना ASLR bypass को जटिल बनाता है, जहाँ attacker को केवल main binary layout पता होता है और वह in-text syscall byte patterns खोजता है।

---

प्रभावशीलता और threat modeling पर बहस

• समर्थन करने वाले विचार:
  • यदि mitigation सस्ता है और attack surface नहीं बढ़ाता, तो उसे shipping लायक माना जाता है।
  • OpenBSD ने ऐतिहासिक रूप से mitigations को ऐसे समय में deploy किया है जब attacks की classes public भी नहीं थीं (उदा., Spectre/Meltdown से पहले hyperthreading को disable करना; “needless” randomness जिसने बाद में DNS cache attacks को रोका)।
  • Low CVE counts और ऐसे mitigations जो vulnerabilities से पहले ही उन्हें रोक दें, अच्छे intuition के प्रमाण के रूप में उद्धृत किए जाते हैं।
• संदेहपूर्ण विचार:
  • वास्तविक-world exploits/CVEs और tested exploit chains के स्पष्ट mapping के बिना mitigations की आलोचना “amorphous” और संभावित रूप से “security theater” के रूप में की जाती है।
  • हर mitigation complexity और long-term maintenance cost जोड़ता है; स्पष्ट threat model के बिना यह कुल security को घटा भी सकता है।
  • कुछ लोग तर्क देते हैं कि यदि mitigation मौजूदा in-the-wild techniques को स्पष्ट रूप से नहीं रोकती, तो यह अधिकतर एक academic exercise है।
  • दूसरे counter करते हैं कि केवल “fixed CVEs” पर ध्यान देना past mistakes को reward करता है और prevented bugs को कम आँकता है।

---

पाया गया implementation bug

• नई code में एक trivial लेकिन वास्तविक bug पाया गया:
  • MAX macro में signed/unsigned mixing attacker को internal count (npins) को negative करने देती है, जिससे under-allocation और attacker-controlled syscall numbers द्वारा indexed out-of-bounds heap writes हो सकती हैं।
  • exploit sketch का उदाहरण crafted “pinned syscall” table entries का उपयोग करके पहले memory poison करता है, फिर npins को -1 पर force करता है, जिसे allocation से पहले small positive value में clamp कर दिया जाता है।
• tooling पर चर्चा:
  • कुछ लोग बताते हैं कि Rust-style integer/typing checks ने इस bug class को रोका हो सकता था।
  • दूसरे point out करते हैं कि C compilers के पास पहले से flags हैं (उदा., sign-compare warnings, sanitizers, overflow traps) जो इसे पकड़ सकते थे, लेकिन वे सार्वभौमिक रूप से enabled नहीं हैं।

---

C बनाम Rust और OpenBSD की सीमाएँ

• Rust को safer integer semantics और type checking के लिए सराहा जाता है, लेकिन:
  • OpenBSD में लगभग tens of millions lines of C हैं, कई platforms हैं, और manpower बहुत सीमित है।
  • core OS code में Rust को rewrite करना या गहराई से integrate करना high-risk और resource-intensive माना जाता है।
• कुछ लोग तर्क देते हैं कि नई security-focused OSes को Rust से शुरू करना चाहिए; अन्य लोग ज़ोर देते हैं कि Rust कोई silver bullet नहीं है और mature C code plus careful tools फिर भी viable रह सकते हैं।

---

मेटा: OpenBSD की security posture और ecosystem

• कुछ प्रतिभागी कहते हैं कि OpenBSD का user base इतना छोटा है कि वहाँ समृद्ध, empirically known “exploit meta” नहीं है, इसलिए बहुत कुछ अन्य platforms से extrapolated है।
• इस बीच तनाव है:
  • वे लोग जो OpenBSD के slogan और reputation को बढ़ा-चढ़ाकर या भ्रामक मानते हैं।
  • वे लोग जो लगातार hardening work और अपेक्षाकृत कम गंभीर holes को इसे पर्याप्त justification मानते हैं, और दूसरों को इसका उपयोग करने से हतोत्साहित करने के aggressive प्रयासों को देखकर हैरान होते हैं।