OpenBSD में एक use-after-free है जो स्थानीय privilege escalation को root तक अनुमति देता है

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

OpenBSD के SysV semaphore code में हाल ही में उजागर हुआ use-after-free bug local users को root तक privileges बढ़ाने देता है, जिससे परियोजना की लगभग त्रुटिहीन security की छवि को चुनौती मिलती है। टिप्पणीकार ध्यान देते हैं कि यह flaw AI-assisted audit (OpenAI और Trail of Bits के “Patch the Planet”) द्वारा मिला था, OpenBSD के एक local privilege escalation की तुलना Linux और FreeBSD में मिली अधिक समस्याओं से करते हैं, और इस पर बहस करते हैं कि codebase size, development practices, और minimal default configurations वास्तविक-विश्व security को कैसे प्रभावित करते हैं। Rust या अन्य memory-safe approaches क्या इस bug class को रोक सकती थीं, और AI-driven vulnerability hunting कितना लागत-प्रभावी है, इस पर भी व्यापक चर्चा है।

कमज़ोरी और प्रभाव

  • CVE OpenBSD ≤7.9 में sys/kern/sysv_sem.c (SysV semaphores) में एक use-after-free का वर्णन करता है, जो स्थानीय privilege escalation (LPE) को root तक सक्षम बनाता है।
  • यह sys_semget() में tsleep के बाद एक context-switch UAF है।
  • टिप्पणीकार इस पर ज़ोर देते हैं कि यह गंभीर है, लेकिन “remote hole” नहीं है।
  • sandboxed प्रक्रियाओं से इसकी पहुँच पर चर्चा होती है; एक linked pledge(2) implementation सुझाव देता है कि sandboxed base daemons सामान्यतः इन syscalls का उपयोग नहीं कर सकते।

खोज और AI-सहायता प्राप्त auditing

  • यह bug संभवतः “Patch The Planet” पहल में उजागर हुआ था (OpenAI models + Trail of Bits), जो open-source projects को scan कर रही थी।
  • कुछ लोगों का अनुमान है कि इसे पहले एक generic bug के रूप में ठीक किया गया; केवल बाद में इसका LPE potential पहचाना गया, संभवतः AI tooling द्वारा। इसे एक अनुमान बताया गया है, पुष्टि नहीं।
  • Patch The Planet के अपने आँकड़े: Linux 24 LPEs, FreeBSD 7, OpenBSD 1, साथ ही कई non-LPE issues।
  • इस पर बहस कि क्या AI-based audits लागत-प्रभावी हैं या पारंपरिक security research को funding देना बेहतर है।

OpenBSD security record और “marketing”

  • OpenBSD का “default install में सिर्फ दो remote holes” slogan एक ओर तकनीकी रूप से सटीक होने के लिए सराहा जाता है, और दूसरी ओर चयनात्मक होने के लिए आलोचना भी झेलता है:
    • Default install minimal है और अधिकांश services disabled हैं, इसलिए वास्तविक-विश्व systems इससे अलग होते हैं।
    • फिर भी, minimal defaults और aggressive hardening (pledge, unveil, W^X, ASLR, आदि) को वास्तविक strengths माना जाता है।
  • कुछ लोगों का तर्क है कि OpenBSD कभी-कभी जिन्हें वह “security bugs” कहता है, उन्हें downplay या filter करता है, आंशिक रूप से इसलिए क्योंकि रिपोर्ट किए गए कई issues overhyped या impractical होते हैं।

Linux/FreeBSD और code size से तुलना

  • कई टिप्पणीकार Linux/FreeBSD में अधिक bugs को इन कारणों से जोड़ते हैं:
    • बड़े codebases और अधिक features/drivers।
    • विकास में अधिक churn।
  • lines-of-code की तुलना का हवाला दिया जाता है; कम LOC को कम bugs से जोड़ा जाता है, हालांकि exact security implications पर बहस होती है।

Local privilege escalation की प्रासंगिकता

  • एक दृष्टिकोण: सामान्य OpenBSD server deployments में, जहाँ untrusted code नहीं चलता, LPEs कम महत्वपूर्ण होते हैं।
  • प्रतिवाद: जब LPEs को RCE या supply-chain attacks के साथ chain किया जाता है, तब वे महत्वपूर्ण हो जाते हैं; defense-in-depth में वे key हैं।

Rust और memory safety पर चर्चा

  • कई लोग बताते हैं कि Rust का ownership model UAF को रोकने के लिए बनाया गया है, इसलिए इस bug का एक सीधा संस्करण संभवतः compile नहीं होता।
  • अन्य लोग kernel की वास्तविकता पर ज़ोर देते हैं:
    • बड़े हिस्सों को unsafe होना पड़ता है, विशेषकर interrupts, DMA, और low-level primitives के आसपास।
    • “safe” Rust की सुरक्षा underlying unsafe code की correctness पर निर्भर करती है।
  • निष्कर्ष: Rust कुछ bug classes को काफी कम करता है, लेकिन kernel vulnerabilities को जादुई रूप से समाप्त नहीं करता।

OpenBSD design trade-offs और features

  • कई लोग तर्क देते हैं कि OpenBSD का अच्छा प्रदर्शन (एक LPE) इसकी संस्कृति, सावधानीपूर्वक engineering, और जानबूझकर चुने गए feature set को दर्शाता है।
  • इस पर बहस है कि क्या OpenBSD वास्तव में “minimal” है:
    • कुछ लोग कहते हैं कि यह security और maintenance कारणों से प्रमुख subsystems (जैसे Bluetooth, “modern” filesystems जैसे ZFS) को छोड़ देता है।
    • अन्य लोग नोट करते हैं कि base system वास्तव में समृद्ध है (जैसे BGP daemons, networking tools), बस इसकी philosophy और scope अलग है।
  • routers के लिए journaling/ZFS की कमी पर सवाल उठाया जाता है; समर्थक fully synchronous FFS की ओर इशारा करते हैं और पूछते हैं कि किसी router data को power loss के बाद वास्तव में क्या बचाना चाहिए।

DNS tooling और OpenWRT tangent

  • एक अलग thread branch dnsmasq के हालिया vulnerability history की आलोचना करता है; कुछ लोगों ने इसे अपने systems से हटा दिया है।
  • OpenWRT में dnsmasq के default उपयोग पर सवाल उठाया जाता है; Unbound (NSD के साथ या बिना) जैसे alternatives सुझाए जाते हैं, लेकिन dnsmasq की “all-in-one” DNS/DHCP/BOOTP/TFTP भूमिका इसे replace करना गैर-आसान बनाती है।