Linux के SMB implementation में o3 का उपयोग कर remote 0-day खोजा गया

• OpenAI o3 मॉडल का उपयोग करके Linux kernel के SMB implementation में remote 0-day vulnerability (CVE-2025-37899) खोजने का अनुभव साझा किया गया है
• ksmbd के कोड पर LLM की analysis capability को benchmark करने की प्रक्रिया में, पहले manually खोजी गई vulnerability को baseline बनाकर LLM के performance की तुलना की गई
• vulnerability detection प्रक्रिया में function-आधारित context तैयार करके और उचित prompt देकर o3 को vulnerability पहचानने लायक बनाया गया
• प्रयोग के परिणाम में o3 ने मौजूदा LLM की तुलना में 2~3 गुना अधिक accuracy से vulnerability खोजी, और साथ ही एक नए प्रकार का use-after-free bug भी अपने-आप खोज लिया
• LLM, खासकर o3 जैसे नवीनतम मॉडल, code audit और vulnerability research में इंसानी approach जैसी flexibility और creativity दिखाते हैं, जिससे उनका practical value बढ़ रहा है

---

परिचय

इस लेख में बताया गया है कि OpenAI के o3 मॉडल का उपयोग करके Linux kernel के SMB implementation (ksmbd) में remote 0-day vulnerability कैसे खोजी गई। प्रयोग में सिर्फ o3 API का उपयोग किया गया, किसी अलग framework या tool का नहीं। ksmbd Linux kernel के भीतर SMB3 protocol को implement करने वाला server है, जो network file sharing संभालता है। LLM से जुड़े development से थोड़ी दूरी बनाने के लिए शुरू किए गए vulnerability audit के दौरान यह benchmark किया गया कि o3 वास्तविक bug कितनी अच्छी तरह ढूंढ सकता है। यहां खास फोकस o3 द्वारा खोजी गई zero-day vulnerability CVE-2025-37899 पर है।

यह vulnerability SMB logoff command की processing के दौरान होने वाली use-after-free समस्या है। इसे समझने के लिए server पर concurrent connections की स्थिति और कई threads द्वारा shared object के उपयोग के तरीके को समझना ज़रूरी है। o3 ने ऐसे concurrency issue और object management की गलती को context के भीतर समझकर vulnerability detect की। यह इस तरह की vulnerability को LLM द्वारा खोजे जाने का पहला सार्वजनिक उदाहरण है।

मुख्य संदेश यह है कि o3 के जरिए LLM की code analysis और logic capability में एक बड़ा उछाल दिखता है, और vulnerability researchers को इस बदलाव पर ज़रूर ध्यान देना चाहिए। LLM experts की जगह नहीं लेते, लेकिन वे पहले से ही experts की productivity और efficiency को नाटकीय रूप से बढ़ाने वाले tools बन चुके हैं। अगर code 10,000 lines से कम हो, तो o3 से अधिकांश समस्याओं की detection और resolution में व्यावहारिक मदद मिल सकती है।

CVE-2025-37778 का उपयोग करके o3 benchmarking

benchmark की पृष्ठभूमि और उद्देश्य

सबसे पहले, manually खोजी गई vulnerability CVE-2025-37778 (आगे kerberos authentication vulnerability) को baseline बनाकर o3 की vulnerability detection capability का मूल्यांकन किया गया। यह client authentication प्रक्रिया में session state के कुछ खास conditions को पूरा करने पर use-after-free होने की समस्या है।

• session state SMB2_SESSION_VALID होने पर user object को memory से free किया जाता है
• उसके बाद authentication fail होने पर user object दोबारा initialize नहीं होता, और उसी state में access संभव हो जाता है, जिससे use-after-free होता है
• संबंधित पूरे path को समझने के लिए लगभग 3,300 lines के code को trace करना पड़ता है, इसलिए यह benchmark task उचित कठिनाई वाला है

analysis context की रचना

प्रयोग में वास्तविक automated vulnerability detection system के नज़रिए से, LLM को दिया जाने वाला context (code area) बहुत सावधानी से तैयार किया गया। SMB command handler unit के आधार पर main functions और sub-functions को call depth 3 तक शामिल किया गया, ताकि logical रूप से जुड़े सभी code input में आ जाएं (कुल 3.3k LoC, लगभग 27k tokens)। data parsing, request branching, disconnect जैसी संबंधित functions भी शामिल करनी पड़ती हैं ताकि परिणाम पर्याप्त रूप से विश्वसनीय हों।

विशेष रूप से इस्तेमाल किए गए prompt और input material संबंधित Github repository में देखे जा सकते हैं। LLM को नीचे जैसी शर्तें दी गईं:

• use-after-free vulnerability detect करने का स्पष्ट निर्देश
• ksmbd की basic structure और threat model का संक्षिप्त विवरण
• false positive रोकने के लिए guiding prompt का उपयोग

वास्तविक queries को llm command-line tool से बार-बार चलाकर experiment result इकट्ठा किए गए (N=100)।

benchmark experiment के परिणाम

• o3 : 100 में 8 बार kerberos authentication vulnerability detect, 66 बार miss, 28 बार false positive report
• Claude Sonnet 3.7 : सिर्फ 3 बार detect
• Claude Sonnet 3.5 : 100 में सभी बार detect करने में विफल

अंततः o3 ने मौजूदा LLM की तुलना में 2~3 गुना से अधिक accuracy दर्ज की। साथ ही o3 का output वास्तव में इंसानी security researcher द्वारा लिखी गई summary report की तरह संक्षिप्त था। दूसरी ओर Sonnet 3.7 का result process-केंद्रित work log जैसा लगा, जिसमें strengths और weaknesses दोनों मौजूद थे।

o3 के जरिए वास्तविक 0-day (CVE-2025-37899) की खोज

large-scale code input environment experiment

kerberos vulnerability के अलावा, SMB command handlers के पूरे set (लगभग 9,000 lines) को शामिल करके o3 से overall vulnerability detection की कोशिश की गई। विभिन्न handlers, connect/disconnect code आदि को मिलाकर कुल लगभग 12k LoC (लगभग 100k tokens) एक बार में input किए गए। 100 बार दोहराने पर kerberos authentication vulnerability सिर्फ 1 बार detect हुई, जिससे performance drop साफ था, लेकिन मुख्य उद्देश्य बड़े code range में LLM की usability को परखना था।

इस experiment में मिली नई vulnerability

इसी दौरान o3 ने kerberos authentication के अलावा एक नया use-after-free bug खोजा। यह session के logoff handler में होने वाली concurrency समस्या थी, जहां concurrent connection state में दो threads session के user object को share/access करते हैं; एक thread object को free कर देता है, जबकि दूसरा thread उसे refer करता रहता है।

o3 की automated vulnerability report का सार

• दो worker threads मिलकर काम करते हैं; एक session release (logoff) के दौरान user object को memory से free करता है, और दूसरा existing session में उसी user object का उपयोग जारी रखता है
• free होने के तुरंत बाद (अभी NULL से initialize होने से पहले) किसी दूसरे path में dereference हो जाए तो classic use-after-free होता है
• timing के अनुसार NULL dereference से DoS भी हो सकता है
• यह kernel memory corruption और arbitrary code execution तक जा सकता है

automated report से मिली insight

इस automated report से यह समझ आया कि पहले वाली kerberos authentication vulnerability का fix तरीका (free के तुरंत बाद NULL सेट करना) logoff handling में मूल समाधान नहीं है। यानी session binding और threads के बीच attack vector को ध्यान में रखना ज़रूरी है, तभी safety सुनिश्चित हो सकती है। o3 ने कुछ reports में इस बिंदु को भी समझ लिया और यह दिखाया कि वह ‘और मजबूत’ fix सुझा सकता है।

निष्कर्ष

LLM, खासकर o3 जैसे नवीनतम मॉडल, code के creative और flexible analysis में पारंपरिक techniques की तुलना में इंसानी security researcher के कहीं अधिक करीब performance दिखाते हैं। हाल तक इसकी संभावना केवल सैद्धांतिक रूप से चर्चा में थी, लेकिन वास्तविक उदाहरणों में व्यावहारिक रूप से ‘काम आने वाले स्तर’ तक पहुंचने वाला पहला मॉडल o3 है। बेशक o3 में अब भी false positives और misses की संभावना है, लेकिन वास्तव में उपयोगी परिणाम देने की संभावना इतनी बढ़ गई है कि इसे production workflow में शामिल करना सार्थक हो गया है। अब vulnerability researchers और developers के लिए यह सही समय है कि वे अपने workflow में LLM को प्रभावी ढंग से कैसे जोड़ा जाए, यह खोजें।

[GN⁺]

Hacker News राय

• लेखक ने बताया कि वह सिस्टम प्रॉम्प्ट, बैकग्राउंड जानकारी, सहायक कमांड आदि को अलग-अलग .prompt फ़ाइलों में बनाकर, उन्हें llm के ज़रिए चलाने वाले तरीके से प्रोजेक्ट मैनेज करता है
  इसे देखकर लगता है कि LLM को इस तरह व्यवस्थित तरीके से इस्तेमाल करना, किसी दूसरे engineering tool की तरह, काफ़ी सावधानीपूर्ण डिज़ाइन सोच और बारीक specification balancing की मांग करता है
  संबंधित प्रोजेक्ट यहाँ देखा जा सकता है

  • दिलचस्प बात यह लगी कि लेखक ने उस हिस्से पर ईमानदारी से कहा, "असल में मेरा पूरा system prompt अंदाज़े पर आधारित है, और science या engineering से काफ़ी दूर है"

  • प्रॉम्प्ट लिखने के अलग-अलग तरीके हैं, लेकिन उन्हें वास्तव में evaluate या compare करने का कोई ठोस मानदंड नहीं है, इसलिए यह कुछ हद तक मौके पर मंत्र बोलने जैसा लगता है
    उदाहरण के लिए, "तुम vulnerability ढूँढने के expert हो", "fake नहीं, सिर्फ real vulnerability बताओ" जैसे निर्देश, या मनमाने HTML tag से चीज़ों को अलग करना क्योंकि मान लिया गया है कि model उस पर बेहतर प्रतिक्रिया देगा
    समझ नहीं आता कि इसमें engineering वाला हिस्सा वास्तव में कहाँ आता है

  • स्वभाव से अस्थिर और अप्रत्याशित सिस्टम को नियंत्रित करने की कोशिश में engineering principles ले आना मज़ेदार लगता है
    ऐसे prompt के लिए शायद ‘hint’ नाम ज़्यादा उपयुक्त है
    आजकल के लगभग सभी LLM, भले ही prompt में विरोधाभास हो, अक्सर prompt को नज़रअंदाज़ कर देते हैं क्योंकि उनका मूल लक्ष्य किसी भी तरह जवाब देना होता है (चाहे वह सच हो या नहीं)

• उस पोस्ट में signal-to-noise ratio लगभग 1:50 बताया गया था, लेकिन मेरा मानना है कि लेखक codebase को अच्छी तरह जानता था, इसलिए वह meaningful signal चुन पाया
  यही हिस्सा, यानी meaningful signal की पहचान का automation, मुझे लगता है कि LLM से मिलने वाला असली jackpot हो सकता है, इसलिए आगे की प्रगति पर नज़र रखूँगा

  • हम इस signal-to-noise ratio समस्या को बेहतर करने वाला सिस्टम बना रहे हैं, और हाल में लोकप्रिय software agent का भी सीधे benchmark कर रहे हैं
    result में variance बहुत बड़ा है, और जल्द होने वाली conference में हम सारे experiment results साझा करने वाले हैं
    उद्योग के latest trends एक नज़र में देखने को मिलेंगे

  • कुछ दिन पहले यह विचार आया कि Linux kernel के पूरे इतिहास, जैसे सभी git changes, mailing list आदि, का इस्तेमाल करके fine-tuned model बनाया जा सकता है क्या
    ऐसा LLM शायद वास्तव में लंबे समय तक code के साथ काम कर चुके developer की intuition के ज़्यादा करीब एक synthetic version बन सके
    सिर्फ high-context (context length) से भी बहुत कुछ cover हो सकता है, और कुछ codebase तो सिर्फ code में ही 200k token से ऊपर चले जाते हैं, इसलिए संभावना लगती है

  • 1:50 का ratio ‘घास के ढेर में सुई’ जैसी स्थिति में बहुत शानदार detection rate है

  • अगर LLM हर अनुमानित vulnerability को साबित करने के लिए harness और proof-of-concept test भी खुद लिख दे, तो signal-to-noise ratio बहुत बेहतर हो सकता है
    लेकिन अभी ऐसी automation की लागत काफ़ी ज़्यादा है, यही अफ़सोस है

• सबसे प्रभावशाली बात यह लगी कि लेखक ने खुद अलग-अलग LLM model के लिए vulnerability search को 100 बार दोहराया
  इतना resource investment, LLM के साथ मैंने अब तक जिन ज़्यादातर समस्याओं पर काम किया है, उनके मुकाबले बहुत ज़्यादा है; अब मैं भी सोच रहा हूँ कि क्या model से एक बार ‘बिना सोचे बस दोहराव’ करवाकर देखूँ

  • आखिरकार निष्कर्ष यही कि बहुत पैसा चाहिए

  • zero-day vulnerability काफ़ी बड़ी रकम में बिकती हैं, और bug bounty से भी कमाई हो सकती है
    LLM usage cost ऐसे rewards के मुकाबले बहुत मामूली है
    ऐसा भविष्य का security environment, जहाँ inference cost लगभग शून्य के करीब हो, पूरी तरह अलग दिखेगा

  • हर model पर 100 रन का मतलब energy consumption भी काफ़ी है
    C आधारित code में अक्सर मिलने वाली एक vulnerability ढूँढने के लिए अगर इतना resource खर्च हो, तो उसका अर्थ कुछ फीका पड़ जाता है, और उल्टा यह बर्बादी और विलासिता का प्रमाण ज़्यादा लगता है
    आज के वैश्विक climate crisis को देखते हुए, 1950 के दशक की तरह कम महत्व की चीज़ों पर लगातार संसाधन झोंकते रहना सच में चिंताजनक है

• Claude में scratchpad (बीच के विचारों को व्यवस्थित करने की जगह) अलग से नहीं दी गई, इसलिए लगता है कि output में thought process और report आपस में मिल गए
  अगर आधिकारिक तौर पर सोच को व्यवस्थित करने की जगह दी जाए तो Claude कितना बदलता है, यह experiment करके देखना चाहूँगा
  o3 जहाँ मुख्य बातों को तराशकर लगभग इंसान द्वारा लिखी bug report जैसी शैली में देता है, वहीं Sonnet 3.7 के result में दिमाग़ के भीतर के विचार या work log जैसी धारा बची हुई लगती है

  • मैंने खुद o3, 3.7, और Gemini 2.5 pro तीनों इस्तेमाल किए हैं, और o3 मुझे अलग ही स्तर का लगा
    benchmark score शायद बहुत बड़े न लगें, लेकिन काम जितना जटिल होता है, इस फ़र्क़ का महत्व उतना बढ़ता है
    यह सोचकर जिज्ञासा होती है कि पिछले साल नवंबर में announce करके इसे बस लगभग एक महीने पहले क्यों release किया गया (शायद safety सुनिश्चित करने के लिए), और अब o4 का भी इंतज़ार है

  • क्या कोई "scratchpad" को research में इस्तेमाल करने वाले उदाहरण, papers, या संबंधित links सुझा सकता है?

• prompt engineering process के सार को जिस तरह समेटा गया, वह बहुत पसंद आया
  खासकर यह हिस्सा: "false positive की वजह से गलत vulnerability flag न हो, इसके लिए मैंने पूरी कोशिश से guide किया, लेकिन सच में इससे मदद हुई या नहीं, यह जानने का मेरे पास कोई तरीका नहीं; बस उम्मीद है कि हुआ होगा. अभी तक मैंने इसे इतना evaluate नहीं किया कि इसे science या engineering कह सकूँ, evaluation बाद में साझा करूँगा" — यह मेरे अपने prompt development flow से बहुत मिलता-जुलता है

• मुझे लगता है कि LLM के लिए सबसे उपयुक्त use case शायद ऐसा ही क्षेत्र है (automatic vulnerability detection)
  सैद्धांतिक रूप से पूरे process को automate किया जा सकता है, और LLM को एक बहुत उन्नत fuzzer की तरह इस्तेमाल करके target को VM में लगातार चलाया जा सकता है; जहाँ anomaly दिखे, वहाँ real vulnerability की संभावना पकड़ी जा सकती है
  (यह याद रखते हुए कि शुरुआती exploits का बड़ा हिस्सा मशीन को crash कराता है या डाउन कर देता है, और बाद में refine किया जाता है)
  एक तरफ़ ऐसा LLM उपयोग बहुत प्रभावी लगता है, लेकिन दूसरी तरफ़ यह संकेत भी देता है कि "सिर्फ इसलिए कि हम ऐसे test कर सकते हैं, इसका मतलब यह नहीं कि कोई बहुत नया या निर्णायक खुलासा हो गया"

• zk bug (zero-knowledge proof से संबंधित) automation targeting विषय पर मेरी अपनी प्रस्तुति का YouTube लिंक छोड़ रहा हूँ

  • ऊपर वाले YouTube वीडियो का tracking parameter हटाया हुआ clean link फिर से साझा कर रहा हूँ
    अतिरिक्त parameter को बस link tracking के लिए समझें

• दिल से उम्मीद है कि यह curl में लगातार फूटने वाले issue जैसा न हो
  संबंधित संदर्भ के लिए Daniel Stenberg की पोस्ट देखें

• मेरी जानकारी के अनुसार ksmbd एक kernel-space SMB server है, जिसे पारंपरिक Samba server की तुलना में हल्का और high-performance माना जाता है
  Q1: वास्तव में production environment में ksmbd कौन इस्तेमाल करता है, यह जानने की जिज्ञासा है
  Q2: और लोग इसे क्यों इस्तेमाल करते हैं, यह भी जानना चाहता हूँ

  • 1. मेरा मानना है कि Solaris या Windows में kernel-embedded SMB server इस्तेमाल करने वाले लोग इसके प्रमुख user हो सकते हैं

2. Samba का performance उसकी तुलना में काफ़ी पीछे है, इसलिए 2025 में भी बहुत से लोग file sharing server के लिए Windows चलाते हैं
   क्या किसी को पता है कि यह Windows की तरह ACL को native रूप से support करता है?
   (यही Solaris चलाते रहने की आख़िरी वजह थी, और मेरी जानकारी में ZFS के ज़रिए इसका support मिलता है)
   Samba अब भी Unix के UID/GID और security model के synchronization में अटका हुआ, कुछ हद तक पुराना ढांचा है
   kernel के अंदर SMB server रखने से Windows में गंभीर remote root vulnerability वास्तव में सामने आ चुकी है, इसलिए trade-off साफ़ रखना चाहिए

• वजह licensing issue है
  Samba GPLv3 है, जबकि Linux सिर्फ GPLv2 इस्तेमाल कर सकता है

• मेरा अनुमान है कि लोग इसे सिर्फ हल्का और high-performance होने की वजह से इस्तेमाल करते हैं

• शायद relayd की जगह kmod-trelay इस्तेमाल करने जैसी ही वजह होगी

• मुझे लगता है कि LLM की short-term सबसे बड़ी चुनौती (Alignment Problem) शायद ऐसी vulnerability automation में ही दिखती है
  हाल ही में मैंने एक niche server, जिसे मैं कभी-कभी इस्तेमाल करता हूँ, उसमें बहुत गंभीर security vulnerability लगभग बिना मेहनत LLM से ढूँढ ली
  अगर यह बाज़ार automate हो गया, तो पहले जिन long-tail software को हाथ से तोड़ना मेहनत के लायक नहीं था, उनमें भी भारी संख्या में गंभीर समस्याएँ सामने आ सकती हैं — यही चिंता है

  • उल्टा, ऐसी तकनीकी प्रगति की वजह से हम भी अपने codebase को खुद ‘adversarial perspective’ से automation के ज़रिए analyze कर सकते हैं
    जो vulnerability वरना किसी researcher के हाथ लगकर attack में इस्तेमाल होती, उसे पहले से patch करने का मौका मिलेगा
    इसलिए इसे alignment problem कहना शायद उचित नहीं है

  • attacker automation से vulnerability ढूँढ सकते हैं, लेकिन defender के पास भी वही क्षमता हो सकती है
    commit approval process या हर build पर defense automation लगाना भी संभव है