▲

AMD가 수정하지 않겠다고 한 원격 코드 실행(RCE) 취약점

 (mrbruh.com)
1P by GN⁺ 8시간전 | ★ favorite | 댓글 1개
  • AMD의 AutoUpdate 소프트웨어에서 원격 코드 실행(RCE) 취약점이 발견되어 보고되었으나, AMD는 이를 수정하지 않기로 결정함
  • 업데이트 구성 파일에 저장된 URL이 HTTP 프로토콜을 사용해 실행 파일을 다운로드하도록 되어 있어, MITM(중간자 공격) 에 취약함
  • 소프트웨어가 다운로드된 파일의 서명 검증을 수행하지 않고 즉시 실행하는 구조로 되어 있음
  • AMD는 이 문제를 “범위 외(out of scope)” 로 분류하고 보안 취약점으로 인정하지 않음
  • 네트워크 공격자가 악성 실행 파일을 배포할 수 있는 위험이 존재함에도 불구하고, 패치가 제공되지 않는 점이 보안상 우려로 지적됨

AMD AutoUpdate의 RCE 취약점 발견 과정

  • 새 게이밍 PC에서 주기적으로 나타나는 콘솔 창 문제를 추적하던 중, 원인이 AMD AutoUpdate 실행 파일임을 확인
  • 프로그램을 디컴파일하는 과정에서 우연히 RCE 취약점을 발견
  • 업데이트 URL이 app.config 파일에 저장되어 있으며, 프로덕션 환경에서도 개발용(Development) URL을 사용하고 있음
  • 해당 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가 이 문제를 수정하지 않기로 한 결정은 보안 커뮤니티 내 논란 가능성을 내포함
  • 네트워크 공격자가 존재할 경우, 악성 코드 배포 경로로 악용될 위험이 있음
▲
GN⁺ 8시간전  [-]
Hacker News 의견들

  • Linux가 모든 드라이버를 번들링하는 점이 좋은 이유는, 저품질 혹은 스파이웨어 같은 드라이버 관리 소프트웨어를 설치할 필요가 없기 때문임
    이런 프로그램들은 샌드박싱이 어렵고 보안상 위험함
    흥미롭게도, 무료로 일하는 배포판 관리자들이 수십억 달러 규모의 하드웨어 벤더보다 보안에 훨씬 능숙한 것처럼 보임

    • 하드웨어 벤더들이 보안에 무능한 건 아님, 단지 우선순위가 다름
      배포판 관리자는 보안을 중요하게 여기지만, 벤더는 다음 세대 하드웨어를 빠르게 출시하는 게 더 중요함
      결국 두 그룹은 서로 다른 목표를 가지고 있음
    • Linus가 만든 조직과 그에 참여하는 수많은 기여자들 덕분에 이런 품질이 유지된다고 생각함
      소수의 영향력 있는 사람들이 묵묵히 좋은 일을 하고 있음
      뉴스에 나오지 않는 사람들이 진짜 실력자라는 신호라고 봄
    • Ryzen Master는 드라이버가 아님
      대부분의 기능은 Linux에서는 사용할 수 없음
    • 원글의 문제는 Windows 관련 이슈인지 명확하지 않음
    • 요즘 벤더들이 로컬 웹 서버를 띄워 브라우저 기반으로 하드웨어를 제어하는 모델로 이동 중인데, 보안상 끔찍한 아이디어로 들림

  • 나는 모든 HTTP 트래픽을 차단해둠
    AMD뿐 아니라 Gigabyte, ASUS 등도 HTTP 접근이 없으면 자동 업데이트가 실패함
    관련 Reddit 스레드에서도 이 문제를 다룸
    암호화되지 않은 HTTP 요청은 프라이버시 누출이자 잠재적 MITM 공격 벡터임
    TLS 스택은 훨씬 공격하기 어려운 표적임

    • 서명된 페이로드라면 HTTP든 HTTPS든 신뢰 수준은 비슷함
      결국 클라이언트의 서명 검증 코드를 믿는 것이므로, GPG를 신뢰하는 것과 다르지 않음
    • 하지만 이렇게 하면 CRL이나 OCSP 조회가 깨지는 것 아님?
    • 많은 Linux 패키지 저장소도 여전히 HTTP만 사용함
      설치된 패키지 버전을 추적하기엔 편리하지만 보안상 불안함

  • 이건 정말 심각한 문제임
    HTTP 리다이렉트를 이용해 임의 코드 실행이 가능한 상황인데, 이런 프로그램이 수많은 PC에 설치되어 있음
    공항에서 Wi-Fi 핫스팟만 열어도 ATI 그래픽 사용자들을 바로 공격할 수 있을 정도임

    • 내 나라에서는 이런 짓 하면 체포됨
      법으로 막는 게 유일한 예방책인 셈임
    • 물론 나쁜 건 맞지만, 이건 업데이트가 있을 때만 작동함
      즉, VPN 없이 위험한 핫스팟에 연결되어 있고, AMD가 최근 업데이트를 배포했으며, 스케줄러가 실행될 때만 해당됨
    • 누가 모르는 사람의 핫스팟에 연결하겠음?
      하지만 지역 ISP가 악의적이라면 공격은 훨씬 쉬움
    • 나는 자동 업데이트를 끄고 씀
      Win98 시절부터 자동 업데이트는 가장 어리석은 기능이라고 생각함

  • DNS 한 번만 오염시켜도 공격이 가능함
    예를 들어, 라우터가 해킹되어 잘못된 IP를 반환하면 HTTP 트래픽에 악성 바이너리를 주입할 수 있음
    HTTPS는 그대로 통과되지만, HTTP는 취약함
    기본 관리자 비밀번호를 그대로 쓰는 사람은 지금이라도 바꿔야 함
    공격자는 DHCP 스푸핑이나 가짜 Wi-Fi로도 같은 일을 할 수 있음

    • SSID 스푸핑이나 전파 재밍으로 사용자를 악성 Wi-Fi에 연결시키는 건 매우 쉬움
    • DNS 응답을 먼저 보내는 것만으로도 공격이 가능함

  • AMD가 이 문제를 버그 바운티 범위 밖이라며 거절한 건 이해하기 어려움
    고객 한 명만 잃어도 바운티보다 손해가 클 텐데, 문서상의 범위를 핑계로 보안을 무시하는 건 잘못된 신호임
    이런 태도는 해커들이 앞으로 AMD에 제보하지 않게 만들 것임

    • 사실 AMD는 이 문제를 여러 번 지적받았음
      그래서 설령 범위 안이더라도 보상받는 게 이상할 정도임

  • 이건 단순한 실수가 아니라 보안 보고 체계의 실패임
    대기업 보안 부서들이 AMD 하드웨어나 업데이트 앱을 금지할지 논의할 수준임
    만약 CVE로 등록됐다면 뉴스에 나올 정도의 사건임
    공격자는 공용 Wi-Fi나 ISP에서 HTTP 트래픽을 감시하며 실행 파일을 감염시킬 수 있음

    • 누구나 CVE를 요청할 수 있으니, 이게 결국 수정으로 이어지는 유일한 길일 수도 있음

  • AMD는 이걸 취약점이 아니라고 한 게 아니라, 버그 바운티 범위 밖이라고 한 것뿐임

    • 하지만 원격에서 권한 상승이 가능한 취약점을 무시하는 건 변명의 여지가 없음
      공격자에게는 “범위 밖”이란 개념이 없는데, AMD는 그걸 정책으로 삼고 있음
      이는 명백한 보안 무책임 정책임
    • 결국 AMD의 범위 문서 자체가 버그라는 말이 나올 정도임

  • 이건 매우 심각한 취약점임
    “MitM이 필요하다”는 이유로 가볍게 넘기면 안 됨
    인터넷 자체가 이미 MitM 환경임

    • 실제로는 MitM조차 필요 없음
      악성 DHCP 서버가 DNS를 조작해도 공격 가능함

  • AMD가 보고 하루 만에 “out of scope / won't fix”로 닫은 건 너무 성급함
    단지 버그 바운티 채널에서 벗어났다는 의미일 뿐, 실제로 수정하지 않겠다는 뜻은 아닐 수도 있음

  • 내 PC에서는 AMD AutoUpdate 터미널이 매일 자정마다 뜨고 닫아야 함
    이제는 완전히 차단하고 수동 업데이트로 돌아갈 이유가 생김

    • 아, 그게 그 창이었군! 며칠째 이유를 찾고 있었음
    • 예전에 Windows 쓸 때 그 콘솔 창이 몇 시간씩 멈춰 있었음
      결국 닫으면 다음 부팅 때 드라이버가 사라져 다시 설치해야 했음
      내가 써본 것 중 최악의 자동 업데이트 프로그램이었음
답변달기