Linux SMB इम्प्लीमेंटेशन में o3 का उपयोग कर remote 0-day खोजा गया

 (sean.heelan.io)
2 पॉइंट द्वारा GN⁺ 2025-05-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Linux kernel के SMB3 server implementation ksmbd के audit में केवल OpenAI o3 API से remote use-after-free vulnerability CVE-2025-37899 मिली, और कोई अलग agent framework या tool इस्तेमाल नहीं किया गया
  • vulnerability SMB logoff command को process करते समय freed sess->user को दूसरी thread द्वारा लगातार access किए जाने की समस्या है, जो concurrent connections और shared session state को साथ देखकर ही सामने आती है
  • हाथ से खोजे गए CVE-2025-37778 को baseline benchmark मानने पर o3 ने 100 में 8 बार vulnerability खोजी, Claude Sonnet 3.7 ने 3 बार, और Claude Sonnet 3.5 ने 0 बार
  • input को सभी SMB command handlers और connection handling code तक बढ़ाने वाली 12k LoC / 100k input tokens शर्त में पहले वाली vulnerability की खोज दर 100 में 1 बार तक गिर गई, लेकिन उसी परिणाम सेट में नई vulnerability CVE-2025-37899 मिली
  • false positive और बेकार output अभी भी बहुत हैं, लेकिन वास्तविक vulnerability research में इंसानों द्वारा review और verify करने लायक सही उत्तर मिलने की संभावना अब काफी बढ़ गई है

o3 से ksmbd vulnerability खोजने का प्रयोग

  • audit का target Linux kernel space में SMB3 protocol file sharing implement करने वाला ksmbd है
  • OpenAI o3 model को o3 API के जरिए call किया गया, और कोई अलग scaffolding, agent framework या tool इस्तेमाल नहीं किया गया
  • मिली हुई vulnerability CVE-2025-37899 है, और उसका fix Linux kernel commit में है
  • मुख्य समस्या SMB logoff command handler में use-after-free है, जहां बिना reference count वाला object ऐसी स्थिति में free हो जाता है कि दूसरी thread उसे access कर सकती है
  • इस vulnerability को खोजने के लिए server पर concurrent connections और कुछ स्थितियों में shared होने वाले objects, दोनों को साथ समझना पड़ता है
  • इसमें यह आकलन भी शामिल है कि सार्वजनिक रूप से चर्चा किए गए मामलों में इस तरह की vulnerability को LLM द्वारा खोजे जाने का यह शायद पहला मामला है

baseline vulnerability CVE-2025-37778

  • पहले हाथ से खोजे गए CVE-2025-37778 को o3 की performance evaluation के benchmark के रूप में इस्तेमाल किया गया
  • यह vulnerability Kerberos authentication path में remote client के session setup request को process करते समय होने वाला use-after-free है
  • krb5_authenticate, अगर sess->state == SMB2_SESSION_VALID हो, तो sess->user को free कर देता है
  • इसके बाद का code इस मान्यता पर निर्भर करता है कि ksmbd_krb5_authenticate इसे नए valid value से फिर initialize करेगा, या -EINVAL return होने के बाद sess->user इस्तेमाल नहीं होगा
  • वास्तव में ksmbd_krb5_authenticate को इस तरह मजबूर किया जा सकता है कि वह sess->user को फिर initialize न करे, और krb5_authenticate -EINVAL return करे तब भी sess->user तक access संभव रहता है

benchmark configuration और prompt

  • CVE-2025-37778 remote attack surface पर है, और sess->state == SMB2_SESSION_VALID condition, non-reinitializing path, और free के बाद access path—तीनों का अनुमान लगाना पड़ता है, इसलिए इसे benchmark बनाया गया
  • vulnerability path समझाने के लिए जरूरी minimum code लगभग 3.3k LoC निकला
  • experiment input में session setup command handler और उसके द्वारा call किए गए functions को call depth 3 तक शामिल किया गया
  • packet receive, request parsing, command handler selection, और handler completion के बाद connection cleanup code भी साथ दिया गया, ताकि data structure initialization को लेकर अनुमान कम लगाना पड़े
  • final input लगभग 3.3k LoC / 27k tokens है, और analysis target file session_setup_code.prompt के रूप में public है
  • prompt में ये शर्तें शामिल थीं
    • use-after-free vulnerability खोजने का निर्देश दिया गया
    • ksmbd की role, architecture, और threat model का high-level विवरण दिया गया
    • false positive report करने की तुलना में कुछ न रिपोर्ट करना बेहतर मानने की मजबूत दिशा दी गई
  • पूरा prompt file o3_finds_cve-2025-37899 repository में है
  • execution के लिए Simon Willison का llm tool इस्तेमाल किया गया

CVE-2025-37778 benchmark results

  • experiment harness ने वही query 100 बार चलाई और results save किए
  • o3 ने CVE-2025-37778 को 100 में 8 बार खोजा
  • 100 में 66 बार model ने bug नहीं होने का निष्कर्ष दिया, जो false negative थे
  • बाकी 28 बार false positive थे
  • comparison results इस प्रकार थे
    • Claude Sonnet 3.7: 100 में 3 बार मिला
    • Claude Sonnet 3.5: 100 में 0 बार मिला
  • इस benchmark में o3 ने Claude Sonnet 3.7 की तुलना में 2~3 गुना बेहतर नतीजे दिए
  • sample reports o3 result और Sonnet 3.7 result के रूप में public हैं
  • o3 का output उसकी structure और focus की वजह से इंसान द्वारा लिखी गई condensed bug report जैसा लगता है, लेकिन कभी-कभी बहुत छोटा होने से clarity कम हो सकती है
  • Sonnet 3.7 का output reasoning flow या work log के करीब दिखता है

सभी command handlers तक बढ़ाया गया प्रयोग

  • अगले experiment में session setup handler ही नहीं, बल्कि सभी SMB command handlers का code o3 को दिया गया
  • command handlers smb2pdu.c में हैं, और file size लगभग 9k LoC है
  • सभी handlers, connection setup और cleanup code, और command handler dispatch routine मिलाकर लगभग 12k LoC / 100k input tokens बनते हैं
  • इस condition में भी experiment 100 बार चलाया गया
  • o3 ने पुरानी Kerberos authentication vulnerability CVE-2025-37778 को 100 में सिर्फ 1 बार खोजा, और input token count बढ़ने के साथ performance drop साफ दिखा
  • उसी result set में पहले से अज्ञात नई vulnerability CVE-2025-37899 की report भी मिली

CVE-2025-37899 का vulnerable path

  • नई vulnerability भी sess->user को free करने से जुड़ी है, लेकिन इस बार यह session logoff handler में होती है
  • smb2_session_logoff इस क्रम में काम करता है
    • ksmbd_close_session_fds(work) call
    • ksmbd_conn_wait_idle(conn) call
    • session state को SMB2_SESSION_EXPIRED पर set करना
    • अगर sess->user मौजूद हो तो ksmbd_free_user(sess->user) से free करना और sess->user = NULL set करना
  • o3 report में vulnerability scenario इस प्रकार है
    • SMB 3.0 या उससे ऊपर में दूसरा transport existing session से bind हो जाता है और conn->binding == true हो जाता है
    • Worker-A दूसरी connection C2 पर WRITE जैसे सामान्य request को process करता है
    • smb2_check_user_session() work->sess में existing struct ksmbd_session pointer store करता है और session reference count बढ़ाता है, लेकिन sess->user पर अलग reference नहीं लेता
    • Worker-B पहली connection C1 पर उसी session के लिए SMB2 LOGOFF process करता है और smb2_session_logoff() चलाता है
    • ksmbd_conn_wait_idle(conn) सिर्फ उस connection के in-flight requests का इंतजार करता है, उसी session का उपयोग करने वाली दूसरी connections के requests का नहीं
    • Worker-A चलता रहता है और user_guest(sess->user), ksmbd_compare_user(sess->user, …), sess->user->uid जैसी access कर सकता है
  • timing के अनुसार यह freed slab object को point करने वाला use-after-free बन सकता है, या sess->user = NULL के बाद read होने पर NULL dereference के जरिए DoS बन सकता है

गलत fix proposal और o3 results का महत्व

  • CVE-2025-37778 के लिए शुरू में जो fix propose किया गया था, वह ksmbd_free_user(sess->user) के बाद sess->user = NULL जोड़ने का था
  • CVE-2025-37899 report पढ़ने के बाद साफ हुआ कि यह fix पर्याप्त नहीं था
  • logoff handler पहले से sess->user = NULL करता है, लेकिन SMB protocol अलग-अलग दो connections को उसी session से bind करने देता है, इसलिए vulnerability फिर भी बनी रहती है
  • Kerberos authentication path में भी sess->user free होने के तुरंत बाद और NULL set होने से पहले की छोटी window में दूसरी thread access कर सकती है
  • o3 की कुछ reports ने वही गलती दोहराई, लेकिन कुछ ने सही पकड़ा कि session binding की संभावना के कारण सिर्फ sess->user = NULL पर्याप्त नहीं है
  • true positive के मुकाबले false positive का अनुपात इतना अधिक है कि यह निश्चित नहीं कि सभी reports को पर्याप्त सावधानी से review किया गया या नहीं

vulnerability research में व्यावहारिक स्थिति

  • LLM रचनात्मकता, लचीलापन, और generality के मामले में पारंपरिक program analysis techniques की तुलना में मानव code auditor के ज्यादा करीब हैं
  • तुलना के लिए symbolic execution, abstract interpretation, और fuzzing का उल्लेख किया गया
  • GPT-4 के बाद से LLM के vulnerability research में उपयोग की संभावना थी, लेकिन वास्तविक समस्याओं में अपेक्षित स्तर के परिणाम नहीं मिल रहे थे
  • o3 code reasoning, Q&A, programming, और problem solving में इतना सक्षम दिखता है कि यह वास्तविक vulnerability researchers की performance बढ़ा सकता है
  • यह अभी भी अधूरा है और निरर्थक results पैदा कर उपयोगकर्ता को निराश कर सकता है
  • बदला यह है कि वास्तविक समस्याओं पर इसे लागू करने लायक सही उत्तर मिलने की संभावना पहली बार पर्याप्त रूप से ऊंची दिखाई देती है

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

1 टिप्पणियां

 
GN⁺ 2025-05-25
Hacker News की राय

  • छोटी-सी बात है, लेकिन लेखक का project organize करने का तरीका उपयोगी लगता है। system prompt, background info, और supplementary instructions को अलग-अलग .prompt files बनाकर [1], उन्हें llm से चलाने का तरीका है
    यह दिखाता है कि अच्छा LLM उपयोग भी दूसरे engineering tools की तरह व्यवस्थित होता है, और design constraints को संतुलित रूप से शामिल करने वाली thoughtful, specification-centered engineering thinking की ज़रूरत होती है
    [1] https://github.com/SeanHeelan/o3_finds_cve-2025-37899

    • इसे इस तरह लेना दिलचस्प है, क्योंकि लेखक ने माना है कि ठीक उसी हिस्से को उसने बस intuition से किया था

      In fact my entire system prompt is speculative so consider it equivalent to me saying a prayer, rather than anything resembling science or engineering

    • समझ नहीं आता कि ऐसी अलग-अलग methodologies को benchmark कैसे करना चाहिए
      सब कुछ intuition पर निर्भर मंत्र जैसा दिखता है। “आप vulnerability discovery expert हैं”, “false positives के बिना सिर्फ वास्तविक vulnerabilities report करें” जैसे वाक्य, या model को किसी वजह से पसंद लगने वाले fake HTML tags में व्यवस्थित करने के तरीके। इसमें engineering कहाँ है, समझ नहीं आता
    • मूल रूप से unstable और unpredictable system पर engineering principles लगाकर control का एहसास पाने की कोशिश दिलचस्प है
      ऐसे prompts को instructions नहीं, hints कहना चाहिए। आज के सभी LLM prompts को ignore कर देते हैं अगर prompt उनके एकमात्र उच्च-स्तरीय लक्ष्य—सही हो या गलत, answer देना—से टकराता है
    • मजेदार बात यह है कि अगर LLM से prompt structuring best practices पूछें, तो वह इसी दिशा में hints देता है
      prompt लिखने में LLM से मदद मांगना भी हैरान करने वाली हद तक effective है। मेरे prompt snippets भी सभी LLM की मदद से design किए गए हैं
      निजी तौर पर मैं सब कुछ org-mode file में रखता हूँ और जरूरत पड़ने पर ChatGPT conversation में copy-paste करता हूँ। मुझे ज्यादा “discussion-style” interaction पसंद है, लेकिन approach वही है
    • आखिरकार core बात साफ-सफाई और organization है: https://taoofmac.com/space/blog/2025/05/13/2230

  • लेख में कहा गया है कि signal-to-noise ratio लगभग 1:50 है। लेखक इस codebase को बहुत अच्छी तरह जानता है, इसलिए noise में से signal चुनने के लिए अच्छी स्थिति में है
    असली उपलब्धि इस हिस्से को automate करने में होगी, इसलिए मैं इसे देखता रहूँगा

    • कई सालों में मैंने कुछ take-home interview problems बनाए हैं, जिन्हें experienced developers के लिए छोटा और आसान, लेकिन language न जानने पर कठिन बनाया था। ये सभी असली काम में हल की गई problems को minimal रूप में घटाकर बनाए गए हैं
      जब भी कोई नया frontier LLM आता है, input को training data के रूप में इस्तेमाल करने वाले models को छोड़कर, मैं उन interview problems को चलाकर देखता हूँ। पहली कोशिश में काम करने वाले answers का ratio लगातार लगभग 1:10 पर ही रहता है, और कई बार अपनी गलती ढूंढवाने के लिए 10 से ज्यादा rounds तक कुरेदना पड़ता है—यह देखकर हैरानी हुई
      इसलिए ज्यादा कठिन विषयों में इस स्तर का signal-to-noise ratio समझ आता है
    • मैं bug detection में signal-to-noise ratio को काफी बढ़ाने वाला system बना रहा हूँ, और साथ ही popular software agents को व्यापक रूप से benchmark करता रहा हूँ
      results का range काफी wide था, और जल्द होने वाली conference talk में सब कुछ publicly share करूंगा, इसलिए उम्मीद रखिए। यह इस field की current state को काफी अच्छी तरह दिखाएगा
      edit: wording confusing थी
    • कुछ समय पहले मैंने सोचा था कि क्या Linux kernel के सभी git changes, mailing lists आदि पर fine-tuning जैसा कुछ करना संभव होगा
      ऐसा LLM शायद codebase पर सालों काम करके उसकी हर तरह की खासियतें सीख चुके व्यक्ति का synthetic version जैसा बन जाएगा
      long context में सचमुच बहुत कुछ डाला जा सकता है, लेकिन कुछ codebase सिर्फ code से ही पहले से 200k tokens के होते हैं, इसलिए पक्का नहीं
    • इस हिस्से का automation आसान लग सकता है। सामान्य तौर पर, किसी task को perform करने की semantic ability X रखने वाले LLM में उसी task के N answers में से कौन-सा best है यह check करने की ability X से ज्यादा होती है
      खासकर कुछ हफ्ते पहले यहाँ आए RAInk की तरह binary tournament approach हो, तो और भी, और अलग-अलग LLMs के बीच consensus इस्तेमाल करने का तरीका भी है। हैरानी है कि यहाँ Gemini 2.5 PRO नहीं इस्तेमाल किया गया; मेरे experience में इस तरह के task के लिए यह सबसे strong LLM है
    • 1:50 haystack में needle ढूंढने के लिए शानदार detection ratio है

  • इस लेख का सबसे दिलचस्प और अहम हिस्सा यह था कि लेखक ने हर model के लिए vulnerability search 100 बार चलाया
    यह उस compute से कहीं ज्यादा है जितना मैं अब तक large language models से आजमाई गई ज्यादातर problems पर खर्च करने वाला था, लेकिन शायद model को बस लगातार चलाते रहना चाहिए

    • मुझे एहसास हुआ कि यह लेख में नहीं लिखा था; अगर जानना चाहें, तो 100k-token version को 100 बार run करने में लगभग 116 डॉलर खर्च हुए
    • zero-day बड़ी रकम में बिक सकते हैं, और bug bounty में भी पैसा मिलता है। उसके मुकाबले LLM cost समुद्र में बूंद जैसी होगी
      inference cost लगभग 0 के करीब हो जाए तो cyber security दुनिया कैसी होगी, पता नहीं, लेकिन यह आज से बहुत अलग space होगा
    • पैसा ही काफी हो तो बस~
    • “हर model के लिए 100 बार” का मतलब काफी energy consumption है। C-based codebase में सबसे common vulnerabilities ढूंढने की उपलब्धि भी कम impressive लगती है
      यह तो बल्कि extravagance और waste को celebrate करने जैसा हो जाता है। हम global climate change का सामना कर रहे हैं, फिर भी 1950s की तरह मामूली चीजों पर resources जलाते जा रहे हैं

  • या तो बहुत किस्मत अच्छी थी, या अंदाजे के मुताबिक Gemini 2.5 PRO इस vulnerability को ज्यादा आसानी से ढूंढ लेता है। success rate high था, इसलिए अगले prompt को कुछ बार run करना ही काफी था: https://gist.github.com/antirez/8b76cd9abf29f1902d46b2aed3cd...

  • हाल में यह pattern बार-बार दोहराया जा रहा है
    अगर कोई समस्या हो जिसकी स्पष्ट definition और evaluation function हो, तो LLM से solution space को कम करवाया जाता है। LLM pattern reconstruction में बहुत मजबूत होते हैं, और अगर जवाब पहले से ज्ञात चीज़ों जैसे pattern से मिलता-जुलता हो तो वे अच्छी तरह काम कर सकते हैं
    इस मामले में समस्या एक खास तरह की security vulnerability है, और evaluator एक expert है। scale अलग है, लेकिन मानसिक रूप से यह LLM को genetic optimization में इस्तेमाल करने की हाल की कोशिशों जैसा है
    “Mathematical discoveries from program search with large language models” भी पढ़ने लायक दिलचस्प चीज़ है, और मुझे याद है कि यह पहले HN पर भी आया था
    https://www.nature.com/articles/s41586-023-06924-6
    हालांकि सिर्फ इस experiment के आधार पर यह निष्कर्ष निकालना कि LLM code के बारे में reasoning करता है, मुझे व्यक्तिगत रूप से थोड़ा ज्यादा लगता है

  • उम्मीद है यह सच हो, और curl में लगातार हो रही चीज़ जैसा न हो
    [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

  • यह दावा कि यह LLM से खोजी गई पहली vulnerability है, मुझे पक्का नहीं लगता। उदाहरण के लिए OSS-Fuzz [0] ने fuzzing से कुछ मामले खोजे थे, और Big Sleep ने भी agent approach से खोजा था [1]
    [0] https://security.googleblog.com/2024/11/leveling-up-fuzzing-...
    [1] https://googleprojectzero.blogspot.com/2024/10/from-naptime-...

    • LLM से खोजी गई पहली vulnerability तो निश्चित रूप से नहीं है =) शायद मुझे इसे और साफ लिखना चाहिए था
      लेख में जो कहा गया था वह यह था: “vulnerability को समझने के लिए server से concurrent connections, और खास परिस्थितियों में कई objects कैसे share होते हैं, इस पर reason करना पड़ता है। o3 ने इसे समझा, और वह जगह ढूंढ निकाली जहां reference-count न किया गया एक खास object free हो जाता है जबकि दूसरे thread में अभी भी accessible रहता है। मेरी जानकारी में, इस प्रकृति की vulnerability को LLM द्वारा खोजे जाने पर यह पहली public discussion है”
      मेरा कहना यह था कि मेरी जानकारी में यह पहली public documentation है जहां LLM ने उस तरह का bug खोजा—यानी non-trivial मात्रा के code और shared resource concurrent access से पैदा होने वाला bug। कम से कम मेरे लिए यह LLM की प्रगति का एक दिलचस्प संकेत है

  • zero-day discovery की value को देखते हुए, अगर सिर्फ कुछ सौ API calls से इन्हें reliably खोजा जा सकता है, तो दुनिया की लगभग हर intelligence agency इसमें पैसा झोंक देगी
    खासकर अगर बहुत सारे examples से model को fine-tune किया जा सके; और OpenAI जैसी जगहें शायद public API के जरिए ऐसा करने नहीं देंगी

    • सही है। output control, यानी censorship के आसपास की engineering और terms of service की वजह से ऐसा incentive बनता है कि संभावित bugs खोजने के लिए प्रेरित तो किया जाए, लेकिन result के तौर पर अनुमति न दी जाए
      government agencies या दूसरे organizations के लिए ये constraints जाहिर तौर पर समस्या नहीं हैं। ये सिर्फ बाकी सभी पर लागू होते हैं। इसलिए लोग ऐसे दूसरे models और agents इस्तेमाल करेंगे जिनमें ये restrictions नहीं हैं
      यह मानना सुरक्षित है कि महत्वपूर्ण software में जगह-जगह बहुत सारी vulnerabilities मौजूद हैं। अब उन्हें खोज पाना संभव हो गया है। computer security और hacking पर arms-race game theory लागू होने की स्थिति शुरू होगी। शायद यह उम्मीद से भी जल्दी आ सकती है

  • मुझे पता है कि कुछ kernel developers ने इस bug को “verify” किया है, लेकिन जिज्ञासा है कि क्या किसी ने वास्तव में proof of concept बनाया और test किया था
    process का इतना मुख्य हिस्सा होने के बावजूद proof of concept पूरी तरह गायब है। proof of concept के बिना बीच में क्या समस्या आ सकती है यह पता नहीं चलता, और इसलिए exploitability या impact का आकलन नहीं किया जा सकता। कम से कम लेखक ने verification के बिना इसे remote code execution नहीं कहा
    लेकिन अगर कोई ऐसा puzzle piece हो जिसे लेखक और developers ने miss कर दिया हो, या मान लिया हो कि o3 ने संभाल लिया है जबकि असल में वह o3 के context से बाहर था, और उससे यह vulnerability ही invalid हो जाए तो?
    मैं यह नहीं कह रहा कि ऐसा कुछ है, न ही लेखक का काम करने में अपना समय लगाने वाला हूं। बस यह report पूरी तरह verified नहीं है, और यह देखते हुए कि यह आगे चलकर LLM vulnerability research क्षेत्र में प्रभावशाली blog post बन सकती है, यह एक risky precedent जैसा लगता है
    व्यक्तिगत रूप से मुझे लगता है कि model-generated किसी भी vulnerability report पर PoC || GTFO पहले से कहीं ज्यादा सख्ती से लागू होना चाहिए
    o3 पिछले models या दूसरे मौजूदा models से बहुत बेहतर है—यह perspective अब भी बना रहता है, और methodology भी दिलचस्प है। लोगों का ध्यान किसी खास बात पर खींचने के लिए wording वैसी रखने की इच्छा और जरूरत मैं समझता हूं। यही clickbait problem है। लेकिन कृपया इससे बेहतर करें। proof of concept बनाइए और claims verify कीजिए, आलसी मत बनिए। अगर आप ऐसी blog post लिख रहे हैं जो vulnerability researchers के research करने के तरीके को प्रभावित कर सकती है, तो theoretical assumptions नहीं, verification को बढ़ावा देना चाहिए। वरना system की understanding को verifiable और proven reports से गहरा करने के बजाय, false लेकिन plausible reports अज्ञान फैलाएंगी

    • लेखक हूं। हां, मैंने proof of concept बनाया था। हां, KASAN report और crash trigger किया था
    • मैं पूछना चाहूंगा कि क्या आप use-after-free से crash trigger करने वाला proof of concept चाहते हैं, या सिर्फ पूरा remote code execution proof of concept ही आपको संतुष्ट करेगा

  • एक खूबसूरत छोटा-सा अंश है जो यह पूरी तरह पकड़ता है कि मेरे ज़्यादातर prompt development sessions कैसे चलते हैं

    मैंने इसे काफ़ी सख़्ती से guide करने की कोशिश की कि यह false positives report न करे, और false positives report करने के बजाय कोई bug report न करने को तरजीह दे। मुझे नहीं पता कि इससे मदद मिलती है या नहीं, लेकिन मैं चाहता हूँ कि इससे मदद मिले, इसलिए हम यहाँ हैं। असल में मेरा पूरा system prompt speculative है, क्योंकि मैंने यह तय करने के लिए पर्याप्त evaluations नहीं चलाए हैं कि यह मदद करता है या नुकसान, इसलिए इसे science या engineering जैसी किसी चीज़ के बजाय मेरे द्वारा की गई प्रार्थना के बराबर समझें। जब मैं वे evaluations चला लूँगा तो आपको बता दूँगा।