AMD का वह remote code execution (RCE) vulnerability जिसे कंपनी ने ठीक न करने का फैसला किया

 (mrbruh.com)
1 पॉइंट द्वारा GN⁺ 2026-02-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AMD के AutoUpdate software में remote code execution (RCE) vulnerability पाई गई और रिपोर्ट की गई, लेकिन AMD ने इसे ठीक न करने का निर्णय लिया
  • update configuration file में stored URL, executable file डाउनलोड करने के लिए HTTP protocol का उपयोग करता है, जिससे यह MITM (man-in-the-middle attack) के लिए असुरक्षित है
  • software की संरचना ऐसी है कि वह downloaded file की signature verification किए बिना उसे तुरंत execute कर देता है
  • AMD ने इस समस्या को “out of scope” के रूप में वर्गीकृत किया और इसे security vulnerability के रूप में स्वीकार नहीं किया
  • नेटवर्क attacker द्वारा malicious executable वितरित किए जाने का जोखिम मौजूद होने के बावजूद, patch उपलब्ध न कराया जाना security concern के रूप में देखा जा रहा है

AMD AutoUpdate में RCE vulnerability मिलने की प्रक्रिया

  • नए gaming PC पर समय-समय पर दिखाई देने वाली console window की समस्या को ट्रैक करते हुए यह पुष्टि हुई कि कारण AMD AutoUpdate executable था
  • program को decompile करने की प्रक्रिया में संयोग से RCE vulnerability का पता चला
  • update URL app.config file में stored है, और production environment में भी development URL इस्तेमाल किया जा रहा है
  • संबंधित URL HTTPS का उपयोग करता है, लेकिन वास्तविक executable download links HTTP पर हैं

vulnerability की तकनीकी समस्या

  • executable file को HTTP के जरिए डाउनलोड किए जाने के कारण, network के भीतर का attacker या ISP स्तर का attacker response में छेड़छाड़ कर उसे malicious file से बदल सकता है
  • AutoUpdate program downloaded file के certificate या signature की verification नहीं करता
  • नतीजतन attacker arbitrary executable वितरित कर सकता है, और program उसे तुरंत execute कर सकता है

AMD की प्रतिक्रिया और रिपोर्ट का परिणाम

  • vulnerability मिलने के बाद AMD को रिपोर्ट किया गया, लेकिन इसे “won’t fix” और “out of scope” के रूप में वर्गीकृत कर बंद कर दिया गया
  • AMD इस vulnerability को security issue नहीं मानता
  • रिपोर्ट और खुलासे की timeline इस प्रकार है
    • 27/01/2026: vulnerability की खोज
    • 05/02/2026: AMD को रिपोर्ट
    • 05/02/2026: “wont fix/out of scope” के रूप में बंद
    • 06/02/2026: blog post प्रकाशित

सुरक्षा प्रभाव

  • HTTP-आधारित update संरचना और signature verification की अनुपस्थिति उपयोगकर्ता सिस्टम को remote code execution हमलों के सामने ला सकती है
  • AMD का इस समस्या को ठीक न करने का फैसला security community में विवाद की संभावना को जन्म दे सकता है
  • यदि network attacker मौजूद हो, तो malware distribution path के रूप में दुरुपयोग का जोखिम है

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

1 टिप्पणियां

 
GN⁺ 2026-02-07
Hacker News की राय

  • Linux के सभी drivers को bundle करके देने की अच्छी वजह यह है कि low-quality या spyware जैसे driver management software install करने की ज़रूरत नहीं पड़ती
    ऐसे प्रोग्राम को sandbox करना मुश्किल होता है और ये security के लिहाज़ से जोखिमभरे हैं
    दिलचस्प बात यह है कि मुफ्त में काम करने वाले distribution maintainers अरबों डॉलर के hardware vendors की तुलना में security में कहीं ज़्यादा सक्षम लगते हैं

    • ऐसा नहीं है कि hardware vendors security में अक्षम हैं, बस उनकी priorities अलग हैं
      distribution maintainers security को अहम मानते हैं, लेकिन vendors के लिए अगली पीढ़ी का hardware जल्दी ship करना ज़्यादा महत्वपूर्ण होता है
      आखिरकार दोनों समूहों के लक्ष्य अलग हैं
    • मेरा मानना है कि Linus द्वारा बनाई गई संरचना और उसमें शामिल अनगिनत contributors की वजह से यह quality बनी रहती है
      कुछ प्रभावशाली लोग चुपचाप अच्छा काम कर रहे हैं
      जो लोग news में नहीं आते, वही असली माहिर होते हैं, मैं इसे उसी का संकेत मानता हूँ
    • Ryzen Master driver नहीं है
      इसकी ज़्यादातर functionality Linux में इस्तेमाल नहीं की जा सकती
    • यह साफ़ नहीं है कि मूल पोस्ट की समस्या Windows से जुड़ा issue है या नहीं
    • आजकल vendors local web server चलाकर browser-based तरीके से hardware control करने वाले मॉडल की ओर बढ़ रहे हैं, और यह security के लिहाज़ से भयानक idea लगता है

  • मैं सारा HTTP traffic block करके रखता हूँ
    सिर्फ AMD ही नहीं, Gigabyte, ASUS वगैरह का auto update भी HTTP access न होने पर fail हो जाता है
    संबंधित Reddit thread में भी इस समस्या पर चर्चा है
    unencrypted HTTP requests privacy leak हैं और संभावित MITM attack vector भी
    TLS stack पर हमला करना कहीं ज़्यादा मुश्किल target है

    • अगर payload signed है, तो HTTP हो या HTTPS, trust level लगभग समान है
      आखिरकार आप client के signature verification code पर भरोसा कर रहे हैं, और यह GPG पर भरोसा करने से अलग नहीं है
    • लेकिन ऐसा करने से CRL या OCSP lookup टूट नहीं जाते?
    • कई Linux package repositories भी अब तक सिर्फ HTTP का इस्तेमाल करती हैं
      installed package versions track करने में यह सुविधाजनक है, लेकिन security के लिहाज़ से अस्थिर लगता है

  • यह सच में गंभीर समस्या है
    HTTP redirect का इस्तेमाल करके arbitrary code execution संभव है, और ऐसा प्रोग्राम अनगिनत PCs पर install है
    एयरपोर्ट पर सिर्फ Wi‑Fi hotspot खोलकर भी ATI graphics users पर तुरंत हमला किया जा सकता है

    • मेरे देश में ऐसा करने पर गिरफ्तारी होती है
      यानी कानून से रोकना ही इसका एकमात्र बचाव है
    • बेशक यह बुरा है, लेकिन यह तभी काम करता है जब update मौजूद हो
      यानी आप VPN के बिना किसी risky hotspot से जुड़े हों, AMD ने हाल ही में update जारी किया हो, और scheduler उस समय run करे
    • कौन किसी अनजान व्यक्ति के hotspot से जुड़ेगा?
      लेकिन अगर local ISP ही malicious हो, तो हमला कहीं आसान हो जाता है
    • मैं auto update बंद करके इस्तेमाल करता हूँ
      Win98 के ज़माने से ही मुझे auto update सबसे बेवकूफ feature लगता है

  • सिर्फ एक बार DNS को poison कर देने से भी हमला संभव है
    उदाहरण के लिए, अगर router hack हो जाए और गलत IP लौटाए, तो HTTP traffic में malicious binary inject की जा सकती है
    HTTPS वैसा ही गुजर जाएगा, लेकिन HTTP कमजोर है
    जो लोग अभी भी default admin password इस्तेमाल कर रहे हैं, उन्हें अभी बदल देना चाहिए
    attacker DHCP spoofing या fake Wi‑Fi से भी यही काम कर सकता है

    • SSID spoofing या radio jamming से users को malicious Wi‑Fi से जोड़ना बहुत आसान है
    • सिर्फ DNS response पहले भेज देने से भी हमला संभव है

  • AMD ने इस मुद्दे को bug bounty scope के बाहर कहकर ठुकरा दिया, यह समझना मुश्किल है
    एक ग्राहक खोने की लागत भी bounty से ज़्यादा हो सकती है, लेकिन दस्तावेज़ी scope का बहाना बनाकर security को नज़रअंदाज़ करना गलत संकेत देता है
    ऐसा रवैया hackers को आगे AMD को report करने से हतोत्साहित करेगा

    • दरअसल AMD को इस समस्या की कई बार जानकारी दी जा चुकी है
      इसलिए यह scope के भीतर भी होता, तो reward मिलना अजीब लगता

  • यह सिर्फ एक साधारण गलती नहीं, बल्कि security reporting system की विफलता है
    बड़ी कंपनियों की security teams इस स्तर पर चर्चा कर सकती हैं कि AMD hardware या update app को ban किया जाए या नहीं
    अगर यह CVE के रूप में दर्ज होता, तो यह news में आने लायक घटना होती
    attacker public Wi‑Fi या ISP पर HTTP traffic की निगरानी करके executable files को infect कर सकता है

    • कोई भी CVE request कर सकता है, इसलिए संभव है कि यही आखिरकार fix तक पहुँचने का एकमात्र रास्ता हो

  • AMD ने यह नहीं कहा कि यह vulnerability नहीं है, उसने सिर्फ इतना कहा कि यह bug bounty scope के बाहर है

    • लेकिन remote से privilege escalation संभव करने वाली vulnerability को नज़रअंदाज़ करने का कोई बचाव नहीं है
      attacker के लिए “out of scope” जैसी कोई चीज़ नहीं होती, लेकिन AMD ने इसे नीति बना लिया है
      यह साफ़ तौर पर security के प्रति गैर-जिम्मेदार नीति है
    • बात यहाँ तक पहुँच गई है कि लोग कह रहे हैं AMD का scope document ही bug है

  • यह बहुत गंभीर vulnerability है
    “MitM चाहिए” कहकर इसे हल्के में नहीं लेना चाहिए
    इंटरनेट खुद ही एक MitM environment है

    • वास्तव में MitM की भी ज़रूरत नहीं
      malicious DHCP server DNS में हेरफेर करके भी हमला कर सकता है

  • AMD ने report के एक दिन के भीतर इसे “out of scope / won't fix” कहकर बंद कर दिया, यह बहुत जल्दबाज़ी थी
    इसका मतलब सिर्फ इतना हो सकता है कि मामला bug bounty channel के बाहर है, ज़रूरी नहीं कि वे सच में इसे fix नहीं करेंगे

  • मेरे PC पर AMD AutoUpdate terminal हर दिन आधी रात को खुल जाता है और मुझे उसे बंद करना पड़ता है
    अब इसे पूरी तरह block करके manual update पर लौटने की वजह मिल गई है

    • अरे, तो वह वही window थी! मैं कई दिनों से उसकी वजह ढूँढ़ रहा था
    • पहले जब मैं Windows इस्तेमाल करता था, वह console window कई-कई घंटों तक अटकी रहती थी
      आखिर में उसे बंद करने पर अगले boot में driver गायब हो जाता था और फिर से install करना पड़ता था
      यह मेरे इस्तेमाल किए गए सबसे खराब auto update programs में से एक था