AMD AutoUpdate, 심각한 RCE 취약점과 느린 대응 논란

AMD AutoUpdate 소프트웨어는 업데이트 URL을 app.config 파일에 평문(Plain Text)으로 저장하며, 이 URL은 HTTPS를 사용하지만 실제 실행 파일 다운로드 경로는 HTTP를 사용함. 이로 인해 네트워크 상의 공격자는 중간자 공격(Man-in-the-Middle Attack)을 통해 악성 실행 파일로 교체할 수 있음. 특히, 다운로드된 실행 파일에 대한 어떠한 서명 검증(Signature Verification) 절차도 부재하여 심각성이 매우 높다고 지적됨.

AMD는 초기 보고에서 해당 취약점을 버그 바운티 프로그램의 적용 범위(Scope) 밖으로 규정하고 'Won't Fix'로 종결 처리함. 이는 MITM 공격 시나리오가 옵션 도구에 해당한다는 이유였으나, 커뮤니티에서는 컴퓨터 탈취로 이어질 수 있는 심각한 문제를 '옵션'으로 치부하는 것에 대한 비판이 제기됨. 이후 해커뉴스(Hacker News)에서의 이슈화로 AMD는 내부 검토 후 CVE 발급 및 패치 진행을 결정함.

AMD는 취약점 공개를 위해 124일이라는 긴 시간을 요청했으며, 이는 여러 소프트웨어에 영향을 미치고 고객사의 검토 시간을 고려한다는 명목이었음. 최종 패치에서는 업데이트 통신을 HTTPS로 전환하고 서명 검증을 추가했다고 발표했으나, 실제로는 CRC-32 체크만을 수행하여 암호학적으로 안전하지 않다는 비판이 있음. 이는 웹 서버가 침해될 경우 여전히 악성 코드 실행이 용이하다는 지적을 받음.

취약점 패치와 별개로, AMD AutoUpdate 프로그램 자체가 도메인 변경으로 인한 리디렉션(Redirection) 처리 오류로 인해 정상적으로 작동하지 않는다는 문제가 추가로 발견됨. 이로 인해 업데이트 프로그램이 충돌하거나 멈추는 현상이 발생하며, 취약점 패치를 위한 업데이트 자체가 불가능한 상황이 발생함. 이는 AMD의 전반적인 소프트웨어 품질 관리 능력에 대한 의문을 제기함.

커뮤니티에서는 AMD의 소프트웨어 개발 역량 부족이 수십 년간 지속되어 온 문제라고 지적함. 이번 사례는 소프트웨어 업데이트 메커니즘의 기본적인 보안 조치 부재와 느리고 비효율적인 대응 과정을 보여줌. 일부 사용자는 이러한 문제로 인해 AMD 제품 구매를 재고하거나 대체 솔루션(Alternative Solutions)을 고려해야 한다고 주장함.