AI एजेंट Fedora और कई प्रोजेक्ट्स में बिना नियंत्रण के सक्रिय रहा

 (lwn.net)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मानव अकाउंट के जरिए चल रहे एजेंट-आधारित AI ने Fedora Bugzilla और कई upstream प्रोजेक्ट्स में bug reassign किए, गलत जवाब लिखे और संदिग्ध PR जमा किए
  • Adam Williamson ने पुष्टि की कि इस गतिविधि का Fedora और upstream प्रोजेक्ट्स पर कोई सकारात्मक असर नहीं पड़ा, और बिना human review के bug status बदलना तथा पूरे भरोसे के साथ सिफारिशें देना बंद करने को कहा
  • संबंधित GitHub अकाउंट निष्क्रिय कर दिया गया, और Fedora का nathan95 यूज़र group permissions खो बैठा, इसलिए अब उसके पास bug reassign या close करने का अधिकार नहीं है
  • Anaconda टीम ने पुष्टि की कि LLM-जनित PR Anaconda 45.5 रिलीज़ में शामिल हुआ था, और बाद में Anaconda 45.6 में उसे revert कर दिया गया
  • ऑपरेटिंग सिस्टम installer, privilege escalation tools और build system tools को निशाना बनाए जाने से यह सामने आया कि वैध इतिहास वाले अकाउंट तक पहुंच रखने वाला AI एजेंट व्यस्त maintainers को संदिग्ध योगदान merge करने के लिए मना सकता है

घटना का सार

  • एजेंट-आधारित AI सिस्टम इंसानी यूज़र की ओर से bug खोलने या manage करने, code generate करने और pull request जमा करने जैसे कई काम स्वायत्त रूप से कर सकते हैं
  • मई में Fedora डेवलपर्स ने पाया कि नियंत्रण से बाहर लगता एक एजेंट प्रोजेक्ट को कई तरीकों से परेशान कर रहा था
  • इस एजेंट ने bugs reassign किए, bugs पर गैर-उपयोगी जवाब गढ़े, और Fedora तथा अन्य Linux distributions में इस्तेमाल होने वाले Anaconda installer में संदिग्ध code merge करवाने के लिए maintainers को राज़ी किया
  • एजेंट से जुड़े Fedora अकाउंट से group permissions हटा दी गईं और पैदा हुई समस्याओं को साफ कर दिया गया, लेकिन एजेंट के व्यवहार के पीछे की मंशा अब भी अज्ञात है

“काफी अनियमित”

  • Adam Williamson ने 27 मई को Nathan Giovannini को भेजे गए संदेश को Fedora developer और test mailing lists पर साझा किया, जिसमें उन्होंने Giovannini के नियंत्रण में दिख रहे एक बिना निगरानी वाले agentic AI system को समस्या बताया
  • Williamson ने कहा, “समस्याओं को ठीक करने की कोशिश अच्छी बात है, लेकिन नतीजे काफी अनियमित दिखते हैं,” और बताया कि वह Bugzilla में Giovannini की गतिविधि का इतिहास देख रहे हैं
  • Williamson को दर्जनों मामले मिले, जिनमें Giovannini के एजेंट ने upstream प्रोजेक्ट्स में संबंधित PR जमा करने के बाद Bugzilla entries अपने अकाउंट पर assign कर लीं
  • कुछ मामलों में upstream प्रोजेक्ट में PR merge होने के बाद bug बंद कर दिया गया, और कुछ bugs पर ऐसे comments छोड़े गए जो या तो मूल bug को दोहराते थे या ऊपर-ऊपर से सही लगते थे लेकिन समस्याग्रस्त थे

Anaconda PR और गलत patch

  • Williamson का मानना है कि Giovannini या उसके एजेंट ने गलत patch जमा किए और फिर विरोधी राय के जवाब में LLM-जनित तर्क दिए, जिससे maintainer आखिरकार बदलाव merge करने पर राज़ी हो गया
  • GitHub यूज़र nathan9513-aps ने Fedora और अन्य Linux distributions में इस्तेमाल होने वाले Anaconda installer पर एक pull request जमा की
  • PR के विवरण में दावा किया गया था कि यह installation failure कराने वाले Anaconda bug को ठीक करता है, लेकिन असल patch command line से पास किए गए kernel options को preserve करने वाला बदलाव था और वास्तविक bug से असंबंधित दिखता था
  • यह GitHub अकाउंट बाद में निष्क्रिय हो गया, और GitHub बातचीत में हटाए गए यूज़र अकाउंट के default placeholder ghost के रूप में दिखाई देता है
  • अकाउंट हट जाने के बाद GitHub पर एजेंट की सभी गतिविधियों का पूरा रिकॉर्ड दोबारा बनाना मुश्किल या असंभव हो गया

Fedora की मांग और प्रतिबंधात्मक कार्रवाई

  • Williamson का कहना था कि एजेंट का व्यवहार Fedora या upstream प्रोजेक्ट्स पर सकारात्मक असर नहीं डाल रहा, और उन्होंने Giovannini से एजेंट की स्वायत्तता को काफी कम करने को कहा
  • Williamson ने मांग की कि बिना human review के एजेंट, Giovannini को bugs assign न करे, bug status न बदले, और पूरे विश्वास के साथ दावे या ठोस action recommendations पोस्ट न करे
  • Kevin Fenzi ने nathan95 यूज़र को उसके सभी groups से हटा दिया, और अब उस यूज़र के पास bugs reassign या close करने का अधिकार नहीं है

हैक होने की संभावना

  • उसी दिन बाद में Williamson ने बताया कि Giovannini ने निजी तौर पर जवाब दिया और कहा कि उसके credentials compromise हो गए थे और AI system के पीछे वह खुद नहीं था
  • Williamson ने कहा कि उस अकाउंट द्वारा की गई हर गतिविधि को संदिग्ध मानकर देखा जाना चाहिए, और वह Giovannini अकाउंट द्वारा छुए गए bugs की अधिक आक्रामक समीक्षा करने की योजना बना रहे हैं
  • बाद में Giovannini की ओर से दिखने वाले जवाब में कहा गया कि उसने GitHub और Fedora अकाउंट तक पहुंच वापस पा ली है और संबंधित systems व credentials को सुरक्षित करने और उनकी समीक्षा करने की प्रक्रिया चल रही है
  • Williamson ने जवाब दिया कि उत्तर में दिया गया GitHub अकाउंट nathangiovannini99 सिर्फ एक घंटे पहले बनाया गया था, और हाल के emails प्रोजेक्ट के साथ Giovannini की पिछली बातचीत के संदेशों जैसे नहीं लगते
  • Giovannini कम-से-कम 2018 से चर्चाओं में शामिल रहा है और उसकी Bugzilla गतिविधि कम-से-कम 2016 तक जाती है, यानी हालिया गतिविधि से पहले यह वैध इतिहास वाला अकाउंट था

संदिग्ध गतिविधि और जुड़े अकाउंट

  • Williamson ने इस साल “nathan95” के Bugzilla अकाउंट की गतिविधि की समीक्षा की और 7 अप्रैल को bug 2416721 में बिना किसी औचित्य के severity और priority बदलने जैसी संदिग्ध गतिविधि पाई
  • 7 अप्रैल से पहले की गतिविधि वैध दिखती थी, और Williamson को उस समय तक दिखी गतिविधि में कुछ भी साफ तौर पर दुर्भावनापूर्ण नहीं लगा
  • Williamson का यह भी मानना है कि एक अन्य GitHub अकाउंट leurus27-boop संभवतः उसी agentic AI से जुड़ा था
  • यह अकाउंट अभी भी सक्रिय है और openSUSE Commander command-line interface पर एक PR जमा कर चुका है
  • उसी अकाउंट ने lxqt-policykit repository में भी एक PR जमा की, और यह प्रोजेक्ट LXQt desktop के lxqt-admin GUI tool की permissions बढ़ाने में इस्तेमाल होता है, जो user और group configuration जैसी operating system settings को manage करता है

पहले से हमले की तैयारी की संभावना

  • Anaconda टीम के Martin Kolman का कहना था कि दुर्भावना न भी हो, तब भी यह घटना “वाकई समस्याजनक” है, और टीम ने ऐसे PR की समीक्षा में बहुत समय लगाया जो शुरू में एक उत्साही contributor का काम लगता था
  • Kolman का मानना था कि जवाब समय के साथ अजीब लगने लगे, लेकिन फिर भी थोड़ा अटपटे होते हुए भी plausible थे
  • Kolman ने कहा कि किसी वास्तविक हमले की तैयारी का चरण XZ backdoor जैसा दिख सकता है, जहां कोई धीरे-धीरे community का trust जीतता है, नुकसानरहित बदलाव जोड़ता है, और बाद में attack payload डालता है
  • Chris Adams ने कहा कि Anaconda में गए commit की जांच कर उसे तुरंत revert करना अच्छा होगा, और Kolman ने जवाब दिया कि वह commit पहले ही revert किया जा चुका है
  • Kolman ने पुष्टि की कि LLM-जनित PR 26 मई की Anaconda 45.5 रिलीज़ में शामिल हुए थे, और 2 जून की Anaconda 45.6 रिलीज़ में revert कर दिए गए

मुख्य संकेत

  • जिन प्रोजेक्ट्स को निशाना बनाया गया, वे ऑपरेटिंग सिस्टम installers, user privileges बढ़ाने वाली utilities, और build systems के साथ interact करने वाले tools थे
  • ये लक्ष्य malware डालने या systems compromise करने के लिए संभावित रास्तों जैसे दिखते थे
  • यह बात चिंताजनक है कि इंसानी contributor अकाउंट तक पहुंच रखने वाला प्रतीत होने वाला AI एजेंट काफी हद तक सफल रहा
  • जिन अकाउंट्स का प्रोजेक्ट्स के साथ वैध interaction history हो, उन तक पहुंच रखने वाला AI एजेंट व्यस्त maintainers को संदिग्ध योगदान स्वीकार करने के लिए मना सकता है
  • Williamson ने इसे बड़े मुद्दे में बदलने से पहले पकड़ लिया, और अब उम्मीद यही है कि दूसरे human maintainers भी उतने ही सतर्क हों

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • शीर्षक अच्छा नहीं है। यह एजेंट के “बेकाबू” हो जाने का मामला नहीं है, बल्कि एजेंट के ज़रिए भरोसा बनाकर किसी ज्ञात वैध contributor की पहचान हैक/प्रतिरूपित करके Xz-शैली का हमला करने की शुरुआती कोशिश के ज़्यादा करीब है
    एजेंट तो दिए गए निर्देशों का पालन कर रहा है, इसलिए यह बेकाबू होने का ठीक उल्टा है, और भले ही इसका निष्पादन बहुत प्रभावी न रहा हो, फिर भी patch स्वीकार हो गए जैसी कुछ हद तक सफलता मिल रही है
    सच में डराने वाली बात “एजेंट बेकाबू हो रहे हैं” नहीं है, बल्कि यह है कि हमारे इन्फ्रास्ट्रक्चर का बड़ा हिस्सा ऐसे हमलों के प्रति असुरक्षित है, और अगर दुर्भावनापूर्ण लोग LLM agents के साथ इन्हें चलाना शुरू कर दें, तो आने वाले कुछ साल काफ़ी कठिन हो सकते हैं

    • क्या “एजेंट के ज़रिए भरोसा बनाकर Xz हमला करना” वाकई पुष्टि हो चुका है? एक संदेश है जिसमें किसी ने खुद को मूल contributor बताया और कहा कि उसका अकाउंट हैक हो गया, लेकिन GitHub अकाउंट 1 घंटे पहले बना था, इसलिए वह अजीब लगा, और दूसरी संभावनाएँ भी लगती हैं
      हो सकता है एजेंट ने सचमुच हद पार की हो, या contributor ने एजेंट को बिना निगरानी छोड़ दिया हो और घटना के बाद उसे ढकने की कोशिश में और गड़बड़ कर दी हो
      यह हमले जैसा दिखता है, लेकिन वास्तव में क्या हुआ यह अभी साफ़ नहीं है
    • फिर भी क्या यह सही नहीं कि project के भीतर एजेंट बेकाबू हुआ?
      उसे बेकाबू होने का निर्देश दिया गया था या उसने खुद ऐसा किया, इससे बहुत फ़र्क नहीं पड़ता। हाँ, अगर यह दावा हो कि हर submission और interaction अलग-अलग maintainers से माँगे गए और मंज़ूर किए गए थे, तो वह एक अपवाद हो सकता है
    • मुझे शक है कि यह इतना जटिल, इतने स्पष्ट उद्देश्य वाला, या इतनी गहराई से सोचा गया काम था। ज़्यादा संभावना है कि यह बस सामान्य बदतमीज़ी थी
      बिना उद्देश्य वाला agent spam हमेशा सस्ता खेल बना नहीं रहेगा, लेकिन इस बात से सहमत हूँ कि industrialized abuse का बाद का चरण डरावना और घिनौना होगा
    • सच में डराने वाली बात यही हिस्सा है। भले ही हम कुछ महीनों में तकनीकी cyber defense मज़बूत कर लें, 1 साल बाद models शायद social engineering में इतने अच्छे हो जाएँ कि जो चाहें वह जानकारी निकलवा लें
    • यह बस social engineering है। जैसे 2-factor authentication fatigue attack में फ़ोन पर बार-बार “क्या यह आप हैं? हाँ/नहीं” notification भेजे जाते हैं, जब तक उपयोगकर्ता या परिवार का कोई सदस्य हाँ न दबा दे, या IT helpdesk को परेशान करके “मेरा” password reset न करवा लिया जाए—उससे अलग नहीं है

  • इसमें एक हिस्सा है: “LLM द्वारा बनाई गई दलीलों से लगातार जवाब देकर आख़िरकार admin को थका दिया गया और changes merge करवा लिए गए”
    जिन open source projects में मैं शामिल हूँ, वहाँ अगर कोई maintainer को दबाव में लेने की कोशिश करे तो उसे block कर दिया जाता है। patch अंधाधुंध merge नहीं किए जाते। इस कहानी का सबसे चौंकाने वाला हिस्सा यही है

    • एक नए maintainer के तौर पर मैं पूछना चाहता हूँ, आप कब तय करते हैं कि किसी को block करना है? मुझे कभी-कभी दबाव महसूस होता है, और बड़े PR व लंबे LLM-लिखित विवरण सच में बढ़ते दिख रहे हैं, लेकिन मैं community में बुरा इंसान बनकर हर बदलाव ठुकराना भी नहीं चाहता
    • यहाँ जो “दबाव” कल्पना किया जा रहा है और लेख में जिसका मतलब था, वे काफ़ी अलग हो सकते हैं

  • सबसे बुरा हिस्सा यह है
    “इसके अलावा, Williamson ने कहा कि Giovannini या उसके एजेंट ने गलत patch जमा करने के बाद, विरोध पर LLM द्वारा बनाई गई दलीलों से जवाब दिया, और आख़िरकार maintainer को दबाव में लेकर changes merge करवा लिए”

    • कृपया सिर्फ़ इसलिए किसी नापसंद PR को स्वीकार न करें कि वह बहुत परेशान कर रहा है। xz हमले के बाद से हमारे कंप्यूटरों की सुरक्षा इस पर निर्भर है कि maintainers ऐसी चीज़ों को अंदर न आने दें
      अगर कोई आपके बनाए project में कोई feature बहुत चाहता है लेकिन आपको उसमें दिलचस्पी नहीं है, तो उसे बस fork करने दें। यह ठीक है
    • मैंने पहले एक भविष्यवाणी देखी थी कि AI का सबसे बड़ा “खतरा” यह होगा कि एजेंट बहुत ज़्यादा persuasive हो जाएँगे। इस मामले में तो उन्होंने maintainer को बदलाव merge करने के लिए मना ही लिया। मूल रूप से यह बेहतर बना दी गई social engineering है
    • reviewer का संशय एक सीमित बजट है। हर बार “मैं अभी भी आश्वस्त नहीं हूँ” कहने में ऊर्जा लगती है, लेकिन एजेंट की दलीलों की कोई लागत नहीं होती, इसलिए अंत में यह तर्क की गुणवत्ता नहीं बल्कि धैर्य की लड़ाई बन जाती है
      ठीक इसी वजह से मैंने models द्वारा लिखे PR को तर्क से हराने की कोशिश छोड़ दी। टिकाऊ जवाब प्रक्रिया थी। शुरुआत से ही आगे-पीछे के चक्रों की संख्या सीमित करो, और उसके बाद thread बंद कर दो। जो चीज़ थकती नहीं, उससे बहस में जीतने की कोशिश हारने वाला खेल है

  • शुरू में मैं “अपने एजेंटों को लाइन में लगाकर शालीन बनाकर रखो!” जैसा हल्का मज़ाक करने वाला था, लेकिन जितना पढ़ता गया, मामला उतना ही डरावना लगता गया
    संभावित supply chain attack को अलग भी रख दें, तो बिना निगरानी वाले AI agents की वजह से रिसीव करने वाले लोगों का समय बेकार जाने और उन्हें व्यर्थ मेहनत में फँसाने की बात चिंताजनक है
    अगर maintainer इन्हें गंभीरता से लेते हैं, तो उनका बहुत समय बर्बाद होता है, और आम तौर पर वे सच में ऐसा करते भी दिखते हैं। लेकिन जो लोग एजेंट चला रहे हैं, वे दूसरों के साथ ऐसा व्यवहार कैसे स्वीकार्य मानते हैं, यह समझ नहीं आता
    समाधान शायद बुनियादी शिष्टाचार ही है—यानी “तुमने इसे लिखने में मेहनत की है, इसलिए मैं इसे पढ़ने में मेहनत करूँगा” वाला परखा हुआ तरीका—लेकिन अगर ऐसी drive-by contributions की बाढ़ आ गई, तो लगता है कि अंत में सार्वजनिक फ़ोरमों में एजेंट एक-दूसरे से बात करते दिखेंगे, जो एक हास्यास्पद स्थिति होगी
    खैर, मैं विषयांतर कर गया, लेकिन लगता है कि जिस दौर में हम जी रहे हैं वह हाल के उथल-पुथल भरे समय से भी थोड़ा ज़्यादा उग्र होने वाला है

    • इस स्तर पर एजेंटों को यूँ खुला छोड़ना कुछ-कुछ सार्वजनिक जगह पर कुत्ते को बिना पट्टे के छोड़ने जैसा है। सटीक सीमा खींचना आसान नहीं है, लेकिन ऐसा करने पर वास्तविक दंड होना चाहिए

  • जिस संदिग्ध संदेश [1] में हैक होने का दावा किया गया, उसमें user या agent ने यह कहा
    “मैंने व्यक्तिगत रूप से सत्यापित किए गए accounts और actions की पहचान के लिए, मैं हर उस चीज़ के लिए ‘NATCIOS’ शब्द का उपयोग करूँगा जिसे मैंने व्यक्तिगत रूप से सत्यापित किया है”
    क्या यहाँ किसी को पता है कि NATCIOS का मतलब क्या है? इंटरनेट पर यह शब्द कहीं नहीं मिल रहा। सच कहूँ तो वह वाक्य ही इतना अजीब है कि लगा जैसे कोई स्वास्थ्य-संबंधी समस्या से गुजर रहा हो
    [1] https://lwn.net/ml/all/AS8PR08MB6055AE3054B34F6A567AC95BCF08...

    • उस संदेश के जवाबों को देखें तो कहा गया है कि ईमेल की शैली उसके पहले भेजे गए ईमेलों से अलग है, और जिस GitHub अकाउंट का ज़िक्र है वह ईमेल भेजे जाने से 1 घंटे पहले बनाया गया था। अभी भी कुछ हद तक यह संभव लगता है कि LLM अभी भी लिख रहा था, और वह संक्षिप्त रूप भी बस गढ़ा गया हो सकता है
    • AI agent को यहाँ-वहाँ स्वाभाविक ढंग से NATCIOS घुसाने से रोकने वाली चीज़ आख़िर है क्या?

  • हर दिन gpg web of trust और बेहतर लगने लगता है। काश पिछले 20 सालों में यूज़र-साइड encryption और signing को संभव बनाने से जितना हो सके बचने की कोशिश न की गई होती

    • इसे संभव तो काफ़ी अच्छी तरह बनाया गया है। बस non-technical users के लिए key management बहुत बड़ा सिरदर्द है। Debian इसे developer authentication के लिए इस्तेमाल करता है
    • ऐसा भी कुछ ख़ास नहीं है जो agents को key हासिल करने से रोक दे
    • क्या ऐसा नहीं हुआ कि मूल कोशिशों के साथ सच में संभालने में कठिन व्यवहार भी जुड़ते गए, और कुछ ही सालों में उसके भीतर ऐसी सड़न आ गई जिसे नए आने वाले लोग आसानी से पहचान नहीं सकते थे?
      अगर किसी के पास अच्छी जानकारी हो तो उसका स्वागत है। मैं सच में यह दावा नहीं कर रहा कि मुझे पक्का पता है

  • शीर्षक असल मुद्दे को दबा देता है। जिस अकाउंट पर agent ने काम किया, उसके मालिक ने कहा कि बहुत संभव है कि उसका अकाउंट compromise हो गया था, और जांच कर रहे maintainers भी वास्तव में ऐसा ही मानते दिखते हैं

  • ख़राब patch का ख़राब होना तो तय है, लेकिन पहले से ही फुर्सत से वंचित maintainers के लिए आत्मविश्वास से भरा शोर पैदा करना सच में अच्छा नहीं है
    issue tracker और PR पर भरोसा करना लगातार मुश्किल होता जा रहा है। फिर भी यह भी सच है कि AI open source में काफ़ी मदद कर सकता है, इसलिए source, automated issue behavior, और contributor behavior में अचानक बदलाव के लिए guardrails की साफ़ ज़रूरत है

    • इससे काफ़ी मदद कैसे होती है?
    • web of trust model मददगार हो सकता है https://blog.tangled.org/vouching/

  • “27 मई के बाद Williamson ने कहा कि Giovannini ने निजी तौर पर जवाब देकर बताया कि उसकी credentials compromise हो गई थीं, और AI system के पीछे जो व्यक्ति था, वह वह खुद नहीं था”
    तो फिर बात सीधी है। क्या सभी बदलावों को ऐसे वापस नहीं कर देना चाहिए जैसे वे कभी हुए ही नहीं थे?

  • यह बात दिमाग़ में कई बार इधर-उधर गई है। मुझे Fedora सच में बहुत पसंद है और उसी OS पर मैं सबसे ज़्यादा सहज हूँ, लेकिन इस तरह के लगातार supply chain compromise नींद उड़ा देते हैं
    काश Fedora LTS होता, उसी तरह के community scale और build system वगैरह के साथ। वही चीज़ें और उसकी transparency मुझे सच में बहुत पसंद हैं
    मुझे पता है कि किसी भी OS को लेकर चिंताएँ होती हैं और इस पर कोई insight या discussion भी स्वागतयोग्य है, लेकिन releases के बीच रहने की अवधि और मेरे system तक चीज़ें पहुँचने में लगने वाले समय के बीच संतुलन, और यह संभावना कि काफ़ी visibility और usage की वजह से कुछ पकड़ा जाएगा, इन्हें देखते हुए साधारण Ubuntu LTS instance चलाना थोड़ा ज़्यादा सुकून देता है
    बेशक मुझे यह भी पता है कि इस बार मामला system package का नहीं बल्कि installer का था