AI द्वारा बनाई गई curl सुरक्षा रिपोर्ट

• curl प्रोजेक्ट bug bounty चलाता है और LLM से बनी लगने वाली सुरक्षा रिपोर्टें बढ़ रही हैं, जिससे वास्तविक vulnerabilities पर प्रतिक्रिया देने के बजाय झूठी रिपोर्टों की जांच में developers का समय खर्च हो रहा है
• अब तक curl ने 70,000 डॉलर से अधिक का भुगतान किया है और 415 रिपोर्टें प्राप्त की हैं, लेकिन वास्तविक सुरक्षा समस्याएं 64 ही हैं और 77 को informative के रूप में वर्गीकृत किया गया है
• समस्या की जड़ यह है कि रिपोर्टें भरोसेमंद अंग्रेज़ी, विस्तृत विवरण और fixes तक के साथ आती हैं, जिससे review cost काफी बढ़ जाती है
• 2023 में CVE-2023-38545 code changes के सार्वजनिक होने का दावा और WebSocket buffer overflow रिपोर्ट मिली, लेकिन क्रमशः न तो कोई वास्तविक public disclosure था और न ही buffer overflow
• AI translation·writing assistance या vulnerability detection tool के रूप में उपयोगी हो सकता है, लेकिन human verification के बिना LLM output जमा करना open source सुरक्षा response की लागत प्रोजेक्ट पर डाल देता है

---

curl bug bounty को मिली low-quality रिपोर्टें

• curl प्रोजेक्ट सुरक्षा समस्याएं रिपोर्ट करने वाले hackers को वास्तविक reward देने वाला bug bounty चलाता है
• reward की संभावना ऐसे “luck seekers” को खींचती है, जो source code में patterns grep करते हैं या सिर्फ basic security scanners चलाकर पर्याप्त analysis के बिना results submit कर देते हैं
• पहले की low-quality रिपोर्टें आम तौर पर जल्दी पहचानी और discard की जा सकती थीं, इसलिए project time की बर्बादी बड़ी समस्या नहीं बनती थी
• अब तक curl bug bounty के नतीजे:
  • 70,000 डॉलर से अधिक rewards paid
  • 415 vulnerability reports received
  • 64 वास्तविक security issues के रूप में confirmed
  • 77 को सामान्य bugs आदि के बराबर informative के रूप में classified किया गया
  • कुल reports में से 66% न तो security issues थीं और न ही सामान्य bugs

भरोसेमंद दिखने वाली झूठी रिपोर्टें ज्यादा खतरनाक क्यों हैं

• false reports जितनी refined होती जाती हैं, उन्हें discard करने तक उतना ही ज्यादा investigation time और energy लगती है
• हर security report को किसी व्यक्ति को खुद पढ़कर उसका वास्तविक meaning judge करना पड़ता है
• security work को अक्सर high priority मिलती है, इसलिए false reports भी दूसरे development work को पीछे धकेल सकती हैं
• जो reports वास्तविक security improve नहीं करतीं, वे annoying bug fixes या new features पर लगने वाला समय छीन लेती हैं
• repetitive low-quality reports से निपटना developers की energy drain भी बढ़ाता है

AI से बनी लगने वाली security reports

• AI एक general-purpose tool है, इसलिए इसे अच्छे कामों के लिए भी इस्तेमाल किया जा सकता है, लेकिन गलत तरीके से भी आसानी से इस्तेमाल हो जाता है
• security issues detect और report करने में AI के productive use की संभावना है, लेकिन curl project को अभी तक कोई अच्छा उदाहरण नहीं मिला है
• फिलहाल ऐसा दिखता है कि users curl code को LLM में डालते हैं और उसके output को security vulnerability report के रूप में submit कर देते हैं
• users AI output को सिर्फ जस का तस paste नहीं करते, बल्कि अपनी sentences भी मिलाते हैं, इसलिए detection और मुश्किल हो जाती है
• भले ही पूरी report AI text से बिल्कुल match न करे, result के तौर पर वह invalid report हो सकती है

सिर्फ AI traces के आधार पर discard करना मुश्किल क्यों है

• कुछ reporters अंग्रेज़ी में fluent नहीं होते, इसलिए उनका intent समझने के लिए कई rounds के questions और answers की जरूरत पड़ती है
• language और culture barriers वास्तव में मौजूद हैं, और ऐसे communication process को अपने-आप में natural माना जा सकता है
• कुछ reporters foreign language में बेहतर communication के लिए AI या दूसरे tools को translation·writing assistance के तौर पर इस्तेमाल करते हैं
• जो reporters अंग्रेज़ी अच्छी तरह नहीं जानते, वे भी वास्तविक security issues खोजकर report कर सकते हैं
• इसलिए text के कुछ हिस्सों में AI-generated traces होने भर से तुरंत discard करना मुश्किल है, और अच्छी तरह लिखी गई false report को पहचानने में ज्यादा समय लगता है

उदाहरण A: CVE-2023-38545 code changes public होने का दावा

• 2023 की शरद ऋतु में curl community को high severity वाली CVE-2023-38545 के जल्द public होने की जानकारी दी गई
• इस issue के public होने से एक दिन पहले HackerOne पर “Curl CVE-2023-38545 vulnerability code changes are disclosed on the internet” नाम की report जमा हुई
• सिर्फ title देखने पर, अगर यह सच होता तो यह बड़ा issue हो सकता था
• लेकिन report typical AI-style hallucination जैसी लगी, जिसमें पुराने security issues के facts और details मिलाकर ऐसी नई बातें बनाई गईं जिनका वास्तविकता से connection नहीं था
• CVE-2023-38545 के changes internet पर public नहीं हुए थे, और जो changes public थे वे intended तरीके से पिछले पुराने issue से संबंधित थे
• reporter ने बताया कि उसने यह issue खोजने के लिए Bard का इस्तेमाल किया था, जिससे error समझना और report बंद करना आसान हुआ

उदाहरण B: WebSocket buffer overflow का दावा

• 28 दिसंबर 2023 की सुबह HackerOne पर “Buffer Overflow Vulnerability in WebSocket Handling” report जमा हुई
• title देखकर यह गंभीर लगती थी, लेकिन curl का WebSocket code अभी experimental feature था, इसलिए bug bounty scope में नहीं आता था
• reporter पहली बार दिखने वाला user था, लेकिन उसकी HackerOne reputation ठीक थी और यह उसकी पहली security report भी नहीं थी
• report अच्छी तरह organized थी और इसमें details, सही अंग्रेज़ी sentences और suggested fix तक शामिल थे
• शुरुआत में यह average first report से बेहतर लगी, और ऐसा लगा कि reporter ने problem समझी है और solution भी propose किया है
• 19 मिनट बाद code कई बार check किया गया, लेकिन दावा किया गया buffer overflow नहीं मिला
• repeated questions और कई hallucinatory answers के बाद इसे वास्तविक problem नहीं माना गया और उसी दिन दोपहर में issue को not applicable के रूप में बंद कर दिया गया
• यह पक्का नहीं है कि ये answers LLM से generated थे या नहीं, लेकिन कई संकेत मौजूद थे

HackerOne block feature और reputation penalty

• शुरुआत में यह माना गया कि HackerOne में project के साथ further communication में reporter को explicitly block करने का feature नहीं है
• कहा गया कि अगर यह feature होता, तो इसका इस्तेमाल किया जाता
• issue को not applicable के रूप में बंद करने पर researcher की HackerOne reputation घटती है, लेकिन अगर किसी single project में यह केवल एक बार होता है, तो penalty effect बहुत छोटा होता है
• बाद के update में जोड़ा गया कि यह feature असल में मौजूद है, और सही जगह नहीं देखी गई थी

और बढ़ेंगी LLM-generated reports

• इस type की reports समय के साथ और common होने की उम्मीद है
• projects generated-by-AI signals को बेहतर detect करना और उनके आधार पर reports discard करना सीख सकते हैं
• हालांकि इससे वे मामले भी नुकसान में आ सकते हैं, जहां AI का इस्तेमाल translation या sentence composition assistance जैसे appropriate कामों के लिए हुआ हो
• आगे AI का इस्तेमाल करके security issues खोजने वाले कुछ tools वास्तव में बेहतर काम करने वाले रूप में सामने आ सकते हैं
• बहुत छोटे स्तर की भी human verification जुड़ जाए तो ऐसे tools की usability और results काफी बेहतर होंगे, ऐसा माना जाता है
• quick reward पाने के लिए shortcuts ढूंढना जारी रहने की संभावना अधिक है, और powerful LLMs तक आसान access वाले environment के कारण HackerOne inbox में और ज्यादा low-quality reports आने की उम्मीद है

[GN⁺]

Hacker News की रायें

• “बिल्कुल! मैं triager द्वारा उठाई गई चिंता को और विस्तार से समझाऊँगा” जैसे वाक्य典型 LLM लहजा हैं, और किसी robot butler जैसे लगते हैं
  असल में बहुत कम लोग इस तरह लिखते दिखे हैं, और “triager” को third person में उल्लेख करना भी अजीब है, जैसे कोई दूसरा पक्ष response को steer कर रहा हो
  LLM का पहचाने जा सकने वाला अपना खास लहजा होना ठीक है, लेकिन चिंता यह नहीं कि LLM इंसानों की तरह बोल रहे हैं, बल्कि यह है कि लोग LLM की तरह बोलना शुरू कर रहे हैं

  • Daniel Stenberg[1] ने अच्छी बात पकड़ी: curl दुनिया भर में इस्तेमाल होता है, इसलिए English native language न होने वाले किसी व्यक्ति का bug report लिखने में LLM की मदद लेना बिल्कुल अजीब नहीं है
    इसलिए केवल इस सतही संकेत से कि English वाक्य LLM-generated लगते हैं, यह नहीं माना जा सकता कि report का content भी LLM ने ही बनाया है

    [1] https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

  • उम्मीद है कहीं कोई dystopian SF लिख रहा होगा जिसमें robot overlords लगातार माफी मांगते हुए कहते हैं, “अंततः, surrender करना है या नहीं, यह आपकी खास जरूरतों और preferences पर निर्भर करता है”

  • “robot butler जैसा लगता है” सुनकर अचानक Butlerian Jihad expression समझ में आ गया

  • भारत में English कभी-कभी औपनिवेशिक दौर के servant class वाली British शैली, यानी तथाकथित “butler style” में सिखाई जाती है
    अगर आपने अब तक ऐसा लहजा नहीं देखा, तो शायद आपने Microsoft enterprise tech support से पाला नहीं पड़ा होगा

  • यह निश्चित रूप से बड़ा red flag है, लेकिन अगर वह कचरा content किसी वास्तविक व्यक्ति ने भेजा होता, तो सिर्फ वह एक लाइन हटानी पड़ती
    content फिर भी संदिग्ध रहता, लेकिन पहचानने के संकेत काफी कम हो जाते

• “beg bounty” के पीछे पड़े लोगों ने पहले ही bug bounty programs चलाना काफी सिरदर्द बना दिया है
  तब वास्तविक इंसानों को समय लगाकर लगभग कुछ भी न होने वाली “bug reports” बनानी पड़ती थीं, लेकिन LLM आ जाए तो fake reports लगभग बिना लागत बनाई जा सकती हैं, इसलिए यह सच में नियंत्रण से बाहर जा सकता है
  निजी तौर पर मुझे लगता है कि यह bug bounty programs का अंत भी हो सकता है
  या फिर इन्हें और बंद करना पड़ सकता है: program participation के लिए आवेदन लेना, सस्ते में verify करना कि व्यक्ति वास्तविक है, सचमुच security researcher है और impact वाले security bugs ढूँढना चाहता है, फिर केवल approved लोगों को bug submit करने और monetary rewards पाने देना

  • ऐसे features देने वाले platforms पहले से मौजूद हैं
    वे जाने-माने researchers को pool के रूप में manage करते हैं और status track करते हैं, और program को कितना public रखना है, यह adjust किया जा सकता है
    कुछ में triagers भी होते हैं, लेकिन project कितना typical है, इस पर success काफी निर्भर करती है
  • एक तरीका submission fee रखने का भी हो सकता है
    पता नहीं मदद करेगा या नहीं, लेकिन machine-generated कचरा submissions को mass scale पर रोकने के लिए deterrent हो सकता है
    सबसे खराब स्थिति यह होगी कि AI कचरे की mass submissions हों, और उसे “solve” करने के लिए उतनी ही खराब AI filtering लगाई जाए, जिससे अच्छे इरादे से participate करने वाले सभी लोगों की overall quality गिर जाए

• पहले मुझे लगा यह post https://news.ycombinator.com/item?id=37904047 की duplicate है, लेकिन पता चला कि यह HackerOne पर curl के खिलाफ आया एक और LLM-generated fake vulnerability report था

  • शुक्र है मैं पागल नहीं था
    पढ़ते हुए मुझे पक्का लगा कि यह पहले देखा है, लेकिन यह पिछली घटना से इतना मिलता-जुलता है कि अजीब लगता है
    क्या Curl जैसे popular projects में लोग अपने resume में एक line जोड़ने के लिए लगातार LLM-written incident reports खुलवाते रहते हैं
  • HackerOne के customers वे companies हैं जो bug bounty programs चलाती हैं
    शायद उन्हें उन लोगों को थोड़ा ज्यादा सावधानी से manage करना चाहिए जो उनके customers को केवल visibility पाने के लिए LLM garbage spam भेज सकते हैं
  • मुझे बिल्कुल पता नहीं था कि ऐसा पहले भी हुआ था
    तो यह मामला और भी स्पष्ट precedent बन जाता है

• सबसे ज्यादा चिंता की बात यह है कि कुछ cents की LLM cost ने महंगे और महत्वपूर्ण engineering time को बहुत बर्बाद कर दिया
  अभी बन रही तरह-तरह की fake information को तोड़ने-समझने में कितना effort लगाना पड़ेगा, यह सोचें तो Brandolini's law जैसा है

  • सही है, LLM में internet के बड़े हिस्से को खराब करने की क्षमता है, और मुझे ठीक से नहीं पता कि यह solve होने वाली problem है या नहीं
    मौजूदा models में दिखने वाले संकेत हैं, लेकिन future models बदलेंगे और बेहतर होंगे
    detection और blocking एक arms race बन जाएगी, जिसे बहुत से productive लोग और platforms शायद follow नहीं कर पाएँगे

• दिलचस्प बात है कि हमने action और effort साबित करने के सबसे low-bandwidth माध्यम, यानी writing, को ऐसी चीज बना दिया है जिसमें यह तय करना कहीं अधिक labour-intensive हो गया है कि कोई वास्तविक action या effort था भी या नहीं
  इसके ripple effects शायद बहुत बड़े होंगे
  यहाँ reporter और administrator दोनों ने वह समय बर्बाद किया जो ज्यादा उपयोगी काम में लग सकता था, और bug bounty व crowdsourcing-based CVE process पूरी तरह signal-to-noise ratio कम होने से कमजोर होते हैं
  नतीजतन spam से निपटने के लिए submission barriers बढ़ने की संभावना बढ़ती है, जिससे कम bugs discover और fix होंगे, security vulnerabilities बढ़ेंगी, और उससे जुड़ी सारी समस्याएँ आएँगी
  यही dynamic दूसरे क्षेत्रों में भी चलेगा, जिससे product reviews, court filings, recipes, how-to guides, medical advice आदि पर भरोसा करना धीरे-धीरे मुश्किल होता जाएगा
  internet के वादों में से एक publishing के democratization के जरिए content का तेज expansion था, लेकिन लगता है कि बचा हुआ फायदा भी अंदर से खोखला होने की प्रक्रिया से गुजर रहा है

• यहाँ length boundary check को मुद्दा बनाना खास तौर पर अजीब है
  क्योंकि user-provided data बिल्कुल इस्तेमाल नहीं हो रहा, और सभी sizes compile time पर static हैं
  curl base64-encoded 16-byte random string, यानी ASCII के 25 bytes और null terminator \0, को static 40-byte buffer में डाल रहा है

  https://github.com/curl/curl/blob/1d8e8c9ad1ff3351386422535f...

और सिर्फ जिज्ञासा से पूछ रहा/रही हूँ: क्या C को मुझसे बेहतर जानने वाला कोई समझा सकता है कि यहाँ keyval local variable क्यों इस्तेमाल किया जा रहा है?
क्या इसे बस heads[3].val = randstr पर सेट करके, header data processing खत्म होने के बाद free() नहीं किया जा सकता?
और keyval 26 या 32 bytes नहीं, बल्कि 40 bytes क्यों है?

• शायद मकसद यह है कि free call करने की जगहें कम हों और उसे भूल जाने की संभावना घटे
  line 580 पर लगता है कि ऐसा हो भी सकता है, लेकिन असल में शायद वह case कभी आता ही नहीं

• अगर ऐसा है, तो randstr और keyval दोनों को हटा देना चाहिए, और चूँकि allocation वैसे भी हो रही है, सीधे &heads[3].val में encode कर देना चाहिए
  फिर भी बेकार का randlen pass करना पड़ेगा, वरना crash होगा
  C के output parameters वाली खूबसूरती यही है
  यह “heap से stack variable में copy” वाला नाच cleanup को भी कम नहीं करता
  क्योंकि encoding के बाद हर हाल में सिर्फ एक ही return है
  हालाँकि अगर पहले ऊपर ज़रूरी variables “बिछा” दिए गए और बाद में एहसास हुआ कि Curl_base64_encode हमेशा allocate करता है, तो समझ आता है कि मौजूदा code ऐसे कैसे बना

• stack का इस्तेमाल लगभग मुफ्त जैसा है, क्योंकि function setup के दौरान space पहले ही reserve हो जाता है और function return होने पर अपने-आप clean up हो जाता है
  heap इस्तेमाल करने पर ज़्यादा काम चाहिए, यह fail हो सकता है, और manual cleanup चाहिए

• high school में सीखे अहम सबकों में से एक था सलीके से पेश किया गया झूठ और भद्दे ढंग से कही गई सच्चाई में फर्क करना
  लेकिन यह मुश्किल हो सकता है
  लोग सही grammar और style को intellectual discourse के primary filter की तरह इस्तेमाल करते हैं, और भाषा के रूप को convincing बनाना LLM बहुत, बहुत अच्छी तरह करते हैं

  • मुझे उत्सुकता है कि उस समय यह सबक आपको और आपके classmates को कितना समझ आया था
    यह बहुत पेचीदा समस्या है, और मुझे लगता है कि ज़्यादातर adults भी इसे handle करने के लिए तैयार नहीं हैं
    औसत इंसान में भी दोनों में फर्क करने की क्षमता काफी होती है, लेकिन समस्या यह है कि text को systematic तरीके से पढ़ने की आदत और मेहनत चाहिए
    देर रात phone scroll करते समय ऐसा करना बहुत मुश्किल है

• अगर यह चिढ़ और समय की बर्बादी न होती, तो dineshsec / dinesh_b का Daniel को strncpy इस्तेमाल करना सिखाने की कोशिश वाला scene मज़ेदार होता
  पहले उसने Daniel को किसी random handle से tag किया, फिर “समस्या वाला code यह है:” कहते हुए ऐसा code गढ़ दिया जो था ही नहीं

  • यह LLM misuse की classic समस्या है
    user कुछ analyze करना चाहता है, लेकिन वह बहुत लंबा है, इसलिए उसे कई requests में काटकर डालता है
    फिर जब तक मुख्य बात तक पहुँचते हैं, original code snippet context से बाहर जा चुका होता है, और model आत्मविश्वास से ऐसी बात उगल देता है जो असल में मौजूद नहीं, पर plausible लगती है

• strcpy या strncpy नहीं, बस memcpy इस्तेमाल करना चाहिए
  खासकर strncpy इन तीनों में निश्चित रूप से सबसे खराब choice है
  code को पहले से source buffer size पता है और यह भी check कर चुका है कि वह destination buffer में fit होगा, इसलिए बेवजह strcpy call करके string length दोबारा नापने की जरूरत नहीं
  सच कहूँ तो LLM की recommendation तो actively discourage करने लायक है
  अगर size नहीं पता, silent truncation की परवाह नहीं, और performance की भी परवाह नहीं है, तो snprintf इस्तेमाल कर सकते हैं
  strncpy buffer के बचे हुए हिस्से को बेवजह 0 से भर देता है
  जब तक आप UI जैसी चीज़ deal नहीं कर रहे, आम तौर पर truncation की परवाह करनी चाहिए, और ऐसे case में strncpy आपको बचा नहीं पाएगा

• इससे related लगता है: https://news.ycombinator.com/item?id=38840907