ช่องโหว่การรันโค้ดระยะไกล (RCE) ที่ AMD ระบุว่าจะไม่แก้ไข

 (mrbruh.com)
1 คะแนน โดย GN⁺ 2026-02-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการค้นพบและรายงานช่องโหว่การรันโค้ดระยะไกล (RCE) ใน ซอฟต์แวร์ AutoUpdate ของ AMD แต่ AMD ตัดสินใจว่าจะไม่แก้ไข
  • URL ที่เก็บอยู่ในไฟล์ตั้งค่าการอัปเดตถูกกำหนดให้ดาวน์โหลดไฟล์ปฏิบัติการผ่าน โปรโตคอล HTTP ทำให้เสี่ยงต่อ MITM (การโจมตีแบบคนกลาง)
  • ซอฟต์แวร์ถูกออกแบบมาให้ รันไฟล์ที่ดาวน์โหลดมาทันทีโดยไม่ตรวจสอบลายเซ็น ของไฟล์
  • AMD จัดปัญหานี้เป็น “อยู่นอกขอบเขต (out of scope)” และไม่ยอมรับว่าเป็นช่องโหว่ด้านความปลอดภัย
  • แม้จะมีความเสี่ยงที่ผู้โจมตีบนเครือข่ายจะสามารถแจกจ่ายไฟล์ปฏิบัติการอันตรายได้ แต่ การไม่มีแพตช์ให้ก็ถูกชี้ว่าเป็นประเด็นน่ากังวลด้านความปลอดภัย

กระบวนการค้นพบช่องโหว่ RCE ใน AMD AutoUpdate

  • ระหว่างติดตามปัญหาหน้าต่างคอนโซลที่เด้งขึ้นมาเป็นระยะบนพีซีเกมมิงเครื่องใหม่ จึงพบว่าสาเหตุคือ ไฟล์ปฏิบัติการ AMD AutoUpdate
  • ระหว่างกระบวนการดีคอมไพล์โปรแกรม ได้ ค้นพบช่องโหว่ RCE โดยบังเอิญ
  • URL สำหรับอัปเดตถูกเก็บไว้ในไฟล์ app.config และแม้ในสภาพแวดล้อมใช้งานจริงก็ยังใช้ URL แบบ Development
  • URL ดังกล่าวใช้ HTTPS แต่ลิงก์ดาวน์โหลดไฟล์ปฏิบัติการจริงกลับเป็น HTTP

ปัญหาทางเทคนิคของช่องโหว่

  • เนื่องจากดาวน์โหลดไฟล์ปฏิบัติการผ่าน HTTP ผู้โจมตีในเครือข่ายหรือแม้แต่ผู้โจมตีในระดับ ISP สามารถดัดแปลงการตอบสนองและสลับเป็นไฟล์อันตรายได้
  • โปรแกรม AutoUpdate ไม่ได้ตรวจสอบใบรับรองหรือลายเซ็นของไฟล์ที่ดาวน์โหลดมา
  • ผลลัพธ์คือผู้โจมตีสามารถแจกจ่ายไฟล์ปฏิบัติการตามอำเภอใจ และโปรแกรมก็สามารถ รันทันที ได้

การตอบสนองของ AMD และผลการรายงาน

  • หลังค้นพบช่องโหว่ได้มีการรายงานไปยัง AMD แต่ถูกปิดเรื่องโดยจัดเป็น “ไม่แก้ไข (won’t fix)” และ “อยู่นอกขอบเขต (out of scope)”
  • AMD ไม่ถือว่าช่องโหว่นี้เป็นปัญหาด้านความปลอดภัย
  • กำหนดการรายงานและการเปิดเผยมีดังนี้
    • 27/01/2026: ค้นพบช่องโหว่
    • 05/02/2026: รายงานต่อ AMD
    • 05/02/2026: ปิดเรื่องเป็น “wont fix/out of scope”
    • 06/02/2026: เผยแพร่บล็อกโพสต์

นัยด้านความปลอดภัย

  • โครงสร้างการอัปเดตผ่าน HTTP และ การไม่มีการตรวจสอบลายเซ็น อาจทำให้ระบบของผู้ใช้เสี่ยงต่อการโจมตีแบบรันโค้ดระยะไกล
  • การที่ AMD ตัดสินใจจะไม่แก้ไขปัญหานี้ สะท้อนถึง ความเป็นไปได้ที่จะเกิดข้อถกเถียงในชุมชนความปลอดภัย
  • หากมีผู้โจมตีอยู่บนเครือข่าย ก็มี ความเสี่ยงที่จะถูกนำไปใช้เป็นเส้นทางแจกจ่ายมัลแวร์

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-07
ความคิดเห็นจาก Hacker News

  • เหตุผลที่ Linux ดีตรงที่ รวมไดรเวอร์ทั้งหมดมาให้ ก็เพราะไม่ต้องไปติดตั้งซอฟต์แวร์จัดการไดรเวอร์คุณภาพต่ำหรือพวกคล้ายสปายแวร์
    โปรแกรมพวกนี้ทำ sandboxing ได้ยากและเสี่ยงด้านความปลอดภัย
    ที่น่าสนใจก็คือ เหมือนว่าเหล่า ผู้ดูแลดิสทริบิวชัน ที่ทำงานฟรีจะเชี่ยวชาญด้านความปลอดภัยมากกว่าผู้ผลิตฮาร์ดแวร์มูลค่าหลายพันล้านดอลลาร์เสียอีก

    • ไม่ใช่ว่าผู้ผลิตฮาร์ดแวร์ ไร้ความสามารถ ด้านความปลอดภัย แค่ให้ความสำคัญไม่เหมือนกัน
      ผู้ดูแลดิสทริบิวชันให้ความสำคัญกับความปลอดภัย แต่ฝั่งผู้ผลิตให้ความสำคัญกับการออกฮาร์ดแวร์รุ่นถัดไปให้เร็วกว่า
      ท้ายที่สุดแล้วทั้งสองกลุ่มมีเป้าหมายต่างกัน
    • คิดว่าคุณภาพแบบนี้คงอยู่ได้เพราะองค์กรที่ Linus สร้างไว้และ ผู้มีส่วนร่วมจำนวนมาก ที่เข้าร่วม
      มีคนทรงอิทธิพลไม่กี่คนที่คอยทำสิ่งดี ๆ อย่างเงียบ ๆ
      มองว่านี่เป็นสัญญาณว่าคนที่ไม่ออกข่าวต่างหากคือคนที่เก่งจริง
    • Ryzen Master ไม่ใช่ไดรเวอร์
      ฟังก์ชันส่วนใหญ่ก็ใช้บน Linux ไม่ได้
    • จากบทความต้นฉบับยังไม่ชัดเจนว่าปัญหานี้เป็นประเด็นเฉพาะของ Windows หรือไม่
    • ช่วงนี้ผู้ผลิตหลายเจ้ากำลังขยับไปสู่โมเดลที่รัน local web server แล้วควบคุมฮาร์ดแวร์ผ่านเบราว์เซอร์ ซึ่งฟังดูเป็น ไอเดียที่แย่มากในแง่ความปลอดภัย

  • ฉันบล็อก ทราฟฟิก HTTP ทั้งหมด เอาไว้
    ไม่ใช่แค่ AMD แต่ Gigabyte, ASUS และเจ้าอื่น ๆ ก็อัปเดตอัตโนมัติไม่สำเร็จถ้าเข้าถึง HTTP ไม่ได้
    เธรด Reddit ที่เกี่ยวข้อง ก็พูดถึงปัญหานี้
    คำขอ HTTP ที่ไม่เข้ารหัสคือการรั่วไหลด้านความเป็นส่วนตัวและเป็น ช่องทางโจมตีแบบ MITM ที่เป็นไปได้
    TLS stack เป็นเป้าหมายที่โจมตีได้ยากกว่ามาก

    • ถ้า payload มีลายเซ็นกำกับ ความน่าเชื่อถือของ HTTP กับ HTTPS ก็ใกล้เคียงกัน
      สุดท้ายก็คือการเชื่อ โค้ดตรวจสอบลายเซ็น ฝั่งไคลเอนต์ ซึ่งไม่ต่างจากการเชื่อ GPG
    • แต่ทำแบบนี้จะไม่ทำให้ การตรวจสอบ CRL หรือ OCSP พังหรือ?
    • แหล่งเก็บแพ็กเกจ Linux หลายแห่งก็ยังใช้แค่ HTTP อยู่
      แม้จะสะดวกต่อการติดตามเวอร์ชันแพ็กเกจที่ติดตั้ง แต่ก็ชวนกังวลด้านความปลอดภัย

  • นี่เป็นปัญหาที่ร้ายแรงจริง ๆ
    ตอนนี้แค่ใช้ HTTP redirect ก็สามารถทำให้เกิด การรันโค้ดตามอำเภอใจ ได้ และโปรแกรมแบบนี้ถูกติดตั้งอยู่ในพีซีจำนวนมหาศาล
    แค่เปิด Wi‑Fi hotspot ในสนามบินก็อาจโจมตีผู้ใช้กราฟิก ATI ได้ทันที

    • ในประเทศของฉัน ถ้าทำแบบนี้จะ ถูกจับ
      เหมือนว่าการมีกฎหมายห้ามคือมาตรการป้องกันอย่างเดียว
    • แน่นอนว่ามันแย่ แต่จะทำงานได้เฉพาะตอนที่มีอัปเดตเท่านั้น
      หมายความว่าต้องเชื่อมต่อ hotspot เสี่ยง ๆ โดยไม่มี VPN, AMD ต้องเพิ่งปล่อยอัปเดตมา และตัว scheduler ต้องรันพอดี
    • จะมีใครไปต่อ hotspot ของคนแปลกหน้าด้วยเหรอ?
      แต่ถ้า ISP ในพื้นที่มีเจตนาร้าย การโจมตีก็ง่ายขึ้นมาก
    • ฉันปิด auto update แล้วใช้แบบนั้นมาตลอด
      ตั้งแต่สมัย Win98 ฉันคิดว่า auto update คือ ฟีเจอร์ที่โง่ที่สุด

  • แค่ทำให้ DNS ปนเปื้อน ครั้งเดียวก็โจมตีได้แล้ว
    เช่น ถ้าเราเตอร์ถูกแฮ็กแล้วตอบกลับ IP ผิด ก็สามารถฉีดไบนารีอันตรายเข้าไปในทราฟฟิก HTTP ได้
    HTTPS ยังผ่านไปได้ตามปกติ แต่ HTTP เปราะบาง
    ใครที่ยังใช้รหัสผ่านผู้ดูแลค่าเริ่มต้นอยู่ก็ควรเปลี่ยนเสียตอนนี้
    ผู้โจมตียังทำแบบเดียวกันได้ด้วย DHCP spoofing หรือ Wi‑Fi ปลอม

    • การ spoof SSID หรือ jam สัญญาณเพื่อบังคับให้ผู้ใช้ไปเชื่อมต่อ Wi‑Fi อันตรายนั้นทำได้ง่ายมาก
    • แค่ส่งคำตอบ DNS ให้ถึงก่อนก็โจมตีได้แล้ว

  • เข้าใจยากว่า AMD ถึงปฏิเสธปัญหานี้โดยบอกว่า อยู่นอกขอบเขต bug bounty
    แค่เสียลูกค้าไปคนเดียวก็น่าจะแพงกว่าค่า bounty แล้ว การอ้างขอบเขตในเอกสารเพื่อเพิกเฉยต่อความปลอดภัยเป็นสัญญาณที่แย่มาก
    ท่าทีแบบนี้จะทำให้แฮ็กเกอร์ไม่อยากรายงานปัญหาให้ AMD ในอนาคต

    • จริง ๆ แล้ว AMD ถูก ชี้ประเด็นนี้มาหลายครั้งแล้ว
      เพราะงั้นต่อให้อยู่ในขอบเขตก็ดูแปลกที่จะยังได้รางวัลตอบแทน

  • นี่ไม่ใช่แค่ความผิดพลาดธรรมดา แต่เป็น ความล้มเหลวของระบบรับรายงานด้านความปลอดภัย
    ถึงขั้นที่ฝ่ายความปลอดภัยขององค์กรใหญ่ ๆ อาจต้องหารือกันว่าจะห้ามใช้ฮาร์ดแวร์ AMD หรือแอปอัปเดตของ AMD หรือไม่
    ถ้าถูกลงทะเบียนเป็น CVE ก็เป็นเรื่องระดับที่ขึ้นข่าวได้เลย
    ผู้โจมตีสามารถดักทราฟฟิก HTTP บน Wi‑Fi สาธารณะหรือที่ ISP แล้วฝังไฟล์ปฏิบัติการที่ติดเชื้อได้

    • ใคร ๆ ก็ขอ CVE ได้ ดังนั้นนี่อาจเป็น หนทางเดียวที่จะนำไปสู่การแก้ไข ก็ได้

  • AMD ไม่ได้บอกว่านี่ไม่ใช่ช่องโหว่ แต่แค่บอกว่า อยู่นอกขอบเขต bug bounty เท่านั้น

    • แต่การเพิกเฉยต่อ ช่องโหว่ยกระดับสิทธิ์จากระยะไกล แบบนี้ไม่มีข้อแก้ตัว
      สำหรับผู้โจมตีไม่มีคำว่า “นอกขอบเขต” แต่ AMD กลับใช้สิ่งนั้นเป็นนโยบาย
      นี่คือ นโยบายไร้ความรับผิดชอบด้านความปลอดภัย อย่างชัดเจน
    • ถึงขั้นมีคนพูดได้ว่า เอกสารขอบเขต ของ AMD เองนั่นแหละคือบั๊ก

  • นี่เป็นช่องโหว่ที่ร้ายแรงมาก
    ไม่ควรทำเหมือนเป็นเรื่องเล็กเพียงเพราะ “ต้องมี MitM”
    ตัวอินเทอร์เน็ตเองก็เป็น สภาพแวดล้อมแบบ MitM อยู่แล้ว

    • จริง ๆ แล้วไม่จำเป็นต้องมี MitM ด้วยซ้ำ
      แค่มี DHCP server อันตรายมาบิดเบือน DNS ก็โจมตีได้แล้ว

  • การที่ AMD ปิดรายงานเป็น “out of scope / won't fix” ภายในวันเดียวหลังถูกรายงานนั้นเร็วเกินไป
    มันอาจหมายถึงแค่ว่าไม่เข้าช่องทาง bug bounty เท่านั้น ไม่ได้แปลว่าจะไม่แก้จริง ๆ เสมอไป

  • บนพีซีของฉัน AMD AutoUpdate terminal เด้งขึ้นมาทุกวันตอนเที่ยงคืนและต้องคอยปิดมัน
    ตอนนี้มีเหตุผลพอแล้วที่จะบล็อกมันถาวรและกลับไปอัปเดตเองแบบ manual

    • อ้อ นั่นเอง หน้าต่างนั้นคืออันนี้นี่เอง! ฉันหาสาเหตุอยู่หลายวันแล้ว
    • เมื่อก่อนตอนใช้ Windows หน้าต่างคอนโซลนั้นค้างอยู่ได้เป็นชั่วโมง ๆ
      สุดท้ายถ้าปิดมัน ไดรเวอร์จะหายไปตอนบูตครั้งถัดไปและต้องติดตั้งใหม่
      มันคือ โปรแกรม auto update ที่แย่ที่สุด ที่ฉันเคยใช้