Kerentanan Remote Code Execution (RCE) yang Diputuskan Tidak Akan Diperbaiki oleh AMD

• Kerentanan remote code execution (RCE) ditemukan dan dilaporkan pada perangkat lunak AutoUpdate milik AMD, tetapi AMD memutuskan untuk tidak memperbaikinya
• URL yang disimpan dalam file konfigurasi pembaruan menggunakan protokol HTTP untuk mengunduh file eksekusi, sehingga rentan terhadap MITM (man-in-the-middle)
• Perangkat lunak ini dirancang untuk langsung menjalankan file yang diunduh tanpa melakukan verifikasi tanda tangan
• AMD mengklasifikasikan masalah ini sebagai “out of scope” dan tidak mengakuinya sebagai kerentanan keamanan
• Meskipun ada risiko bahwa penyerang jaringan dapat mendistribusikan file eksekusi berbahaya, tidak adanya patch yang disediakan dinilai menimbulkan kekhawatiran keamanan

---

Proses Penemuan Kerentanan RCE di AMD AutoUpdate

• Saat menelusuri masalah jendela konsol yang muncul secara berkala di PC gaming baru, ditemukan bahwa penyebabnya adalah file eksekusi AMD AutoUpdate
• Dalam proses dekompilasi program, kerentanan RCE ditemukan secara tidak sengaja
• URL pembaruan disimpan dalam file app.config, dan bahkan di lingkungan produksi masih menggunakan URL Development
• URL tersebut memakai HTTPS, tetapi tautan unduhan file eksekusi yang sebenarnya menggunakan HTTP

Masalah Teknis pada Kerentanan

• Karena file eksekusi diunduh melalui HTTP, penyerang di jaringan atau penyerang pada level ISP dapat memanipulasi respons dan menggantinya dengan file berbahaya
• Program AutoUpdate tidak melakukan verifikasi sertifikat atau tanda tangan pada file yang diunduh
• Akibatnya, penyerang dapat mendistribusikan file eksekusi arbitrer, dan program dapat langsung menjalankannya

Tanggapan AMD dan Hasil Pelaporan

• Setelah kerentanan ditemukan, laporan dikirim ke AMD, tetapi ditutup dengan klasifikasi “won’t fix” dan “out of scope”
• AMD tidak menganggap kerentanan ini sebagai masalah keamanan
• Jadwal pelaporan dan pengungkapan adalah sebagai berikut
  • 27/01/2026: Kerentanan ditemukan
  • 05/02/2026: Dilaporkan ke AMD
  • 05/02/2026: Ditutup sebagai “wont fix/out of scope”
  • 06/02/2026: Blog dipublikasikan

Implikasi Keamanan

• Struktur pembaruan berbasis HTTP dan tidak adanya verifikasi tanda tangan dapat membuat sistem pengguna terekspos pada serangan remote code execution
• Keputusan AMD untuk tidak memperbaiki masalah ini berpotensi memicu kontroversi di komunitas keamanan
• Jika ada penyerang jaringan, terdapat risiko penyalahgunaan sebagai jalur distribusi malware

[GN⁺]

Komentar Hacker News

• Salah satu alasan bagus mengapa Linux membundel semua driver adalah karena tidak perlu memasang perangkat lunak pengelola driver berkualitas rendah atau semacam spyware
  Program seperti ini sulit di-sandbox dan berisiko dari sisi keamanan
  Menariknya, para maintainer distribusi yang bekerja gratis tampak jauh lebih mahir soal keamanan dibanding vendor perangkat keras bernilai miliaran dolar

  • Bukan berarti vendor perangkat keras tidak kompeten dalam keamanan, hanya saja prioritasnya berbeda
    Maintainer distribusi menganggap keamanan itu penting, sedangkan vendor lebih mementingkan peluncuran generasi perangkat keras berikutnya secepat mungkin
    Pada akhirnya kedua kelompok ini punya tujuan yang berbeda
  • Saya rasa kualitas seperti ini bisa dipertahankan berkat organisasi yang dibangun Linus dan banyak sekali kontributor yang ikut di dalamnya
    Ada segelintir orang berpengaruh yang diam-diam terus melakukan hal baik
    Saya melihat ini sebagai tanda bahwa orang yang tidak masuk berita justru adalah yang benar-benar andal
  • Ryzen Master itu bukan driver
    Sebagian besar fiturnya tidak bisa dipakai di Linux
  • Tidak jelas apakah masalah di tulisan asli ini memang isu yang terkait Windows
  • Belakangan ini vendor bergerak ke model yang menyalakan server web lokal untuk mengendalikan perangkat keras lewat browser, dan itu terdengar seperti ide yang mengerikan dari sisi keamanan

• Saya memblokir semua trafik HTTP
  Bukan cuma AMD, Gigabyte, ASUS, dan lainnya juga gagal melakukan pembaruan otomatis jika tidak ada akses HTTP
  Thread Reddit terkait juga membahas masalah ini
  Permintaan HTTP tanpa enkripsi adalah kebocoran privasi sekaligus potensi vektor serangan MITM
  Stack TLS adalah target yang jauh lebih sulit diserang

  • Jika payload-nya ditandatangani, tingkat kepercayaannya mirip baik lewat HTTP maupun HTTPS
    Pada akhirnya yang dipercaya adalah kode verifikasi tanda tangan di sisi klien, jadi tidak berbeda jauh dari mempercayai GPG
  • Tapi kalau begitu bukankah pemeriksaan CRL atau OCSP jadi rusak?
  • Banyak repositori paket Linux juga masih hanya memakai HTTP
    Memang memudahkan pelacakan versi paket yang terpasang, tetapi terasa tidak aman dari sisi keamanan

• Ini masalah yang benar-benar serius
  Dengan memakai redirect HTTP, situasinya memungkinkan eksekusi kode arbitrer, dan program seperti ini terpasang di sangat banyak PC
  Sampai-sampai cukup membuka hotspot Wi‑Fi di bandara untuk langsung menyerang pengguna kartu grafis ATI

  • Di negara saya, melakukan hal seperti ini bisa ditangkap
    Jadi pada dasarnya satu-satunya pencegahan adalah dicegah lewat hukum
  • Tentu ini tetap buruk, tetapi ini hanya bekerja saat ada pembaruan
    Artinya, harus terhubung ke hotspot berbahaya tanpa VPN, AMD baru saja merilis pembaruan, dan scheduler sedang berjalan
  • Siapa yang mau terhubung ke hotspot orang yang tidak dikenal?
    Tetapi jika ISP lokal berniat jahat, serangannya jadi jauh lebih mudah
  • Saya mematikan pembaruan otomatis
    Sejak era Win98 saya selalu menganggap pembaruan otomatis sebagai fitur paling bodoh

• Serangan bisa dilakukan hanya dengan meracuni DNS satu kali
  Misalnya, jika router diretas dan mengembalikan IP yang salah, biner berbahaya bisa disisipkan ke trafik HTTP
  HTTPS akan tetap aman, tetapi HTTP rentan
  Orang yang masih memakai kata sandi admin bawaan sebaiknya menggantinya sekarang juga
  Penyerang juga bisa melakukan hal yang sama lewat DHCP spoofing atau Wi‑Fi palsu

  • Spoofing SSID atau jamming sinyal untuk membuat pengguna terhubung ke Wi‑Fi berbahaya itu sangat mudah
  • Serangan juga bisa dilakukan hanya dengan mengirim respons DNS lebih dulu

• Sulit dipahami mengapa AMD menolak masalah ini dengan alasan di luar cakupan bug bounty
  Kehilangan satu pelanggan saja mungkin lebih merugikan daripada nilai bounty, jadi mengabaikan keamanan dengan berlindung di balik cakupan dokumen memberi sinyal yang buruk
  Sikap seperti ini akan membuat para peretas enggan melapor ke AMD di masa depan

  • Sebenarnya AMD sudah beberapa kali diberi tahu soal masalah ini
    Jadi bahkan jika ini masuk cakupan pun, rasanya aneh kalau sampai diberi imbalan

• Ini bukan sekadar kesalahan sederhana, melainkan kegagalan sistem pelaporan keamanan
  Sampai-sampai departemen keamanan perusahaan besar layak mempertimbangkan untuk melarang perangkat keras AMD atau aplikasi pembaruannya
  Jika sudah terdaftar sebagai CVE, ini akan menjadi insiden yang layak diberitakan
  Penyerang bisa memantau trafik HTTP di Wi‑Fi publik atau ISP lalu menginfeksi file eksekusi

  • Siapa pun bisa meminta CVE, jadi ini mungkin akhirnya menjadi satu-satunya jalan menuju perbaikan

• AMD bukan mengatakan ini bukan kerentanan, melainkan hanya mengatakan bahwa ini di luar cakupan bug bounty

  • Namun mengabaikan kerentanan yang memungkinkan eskalasi hak akses dari jarak jauh tidak punya alasan pembenar
    Bagi penyerang tidak ada konsep “di luar cakupan”, tetapi AMD menjadikannya sebagai kebijakan
    Ini jelas merupakan kebijakan yang tidak bertanggung jawab terhadap keamanan
  • Sampai-sampai orang bisa bilang bahwa dokumen cakupan AMD itulah bug yang sebenarnya

• Ini kerentanan yang sangat serius
  Jangan dianggap remeh hanya karena “membutuhkan MitM”
  Internet itu sendiri sudah merupakan lingkungan MitM

  • Bahkan MitM pun sebenarnya tidak diperlukan
    Serangan tetap bisa dilakukan jika server DHCP berbahaya memanipulasi DNS

• AMD menutup laporan ini sehari setelah pelaporan dengan status “out of scope / won't fix” terasa terlalu tergesa-gesa
  Itu mungkin hanya berarti keluar dari kanal bug bounty, belum tentu berarti mereka benar-benar tidak akan memperbaikinya

• Di PC saya, terminal AMD AutoUpdate muncul setiap hari tepat tengah malam dan harus saya tutup
  Sekarang ada alasan untuk memblokirnya sepenuhnya dan kembali ke pembaruan manual

  • Oh, jadi itu jendela yang itu! Sudah beberapa hari saya mencari tahu penyebabnya
  • Dulu saat masih memakai Windows, jendela konsol itu pernah macet berjam-jam
    Akhirnya kalau ditutup, drivernya malah hilang saat boot berikutnya dan harus dipasang ulang
    Itu adalah program pembaruan otomatis terburuk yang pernah saya pakai