AMD가 수정하지 않으려 했던 RCE

새로 맞춘 게이밍 PC에서 주기적으로 팝업되는 짜증 나는 콘솔 창 때문에 여러 번 흐름이 끊긴 끝에, 나는 문제의 실행 파일이 AMD의 AutoUpdate 소프트웨어라는 것을 찾아낼 수 있었다.

좌절감 속에서 나는 이 소프트웨어가 어떻게 작동하는지 알아내기 위해 디컴파일(Decompiling)하여 응징하기로 결심했고, 그 과정에서 우연히 아주 사소한 원격 코드 실행 (RCE, Remote Code Execution) 취약점을 발견했다.

내가 처음 발견한 것은 그들이 업데이트 URL을 프로그램의 app.config에 저장하고 있다는 점이었다. 비록 운영 환경(Production)에서 그들의 "Develpment" URL을 사용한다는 점이 다소 이상하긴 하지만, HTTPS를 사용하고 있으므로 완전히 안전하다.

진짜 문제는 이 .xml URL을 웹 브라우저에서 열었을 때, 모든 실행 파일 다운로드 URL이 HTTP를 사용하고 있다는 사실을 깨닫는 순간 시작된다.

이는 네트워크상의 악의적인 공격자나, 귀하의 ISP(인터넷 서비스 제공업체)에 접근할 수 있는 국가 차원의 공격자가 중간자 공격 (MITM, Man-in-the-middle)을 쉽게 수행하여 네트워크 응답을 자신들이 선택한 임의의 악성 실행 파일로 교체할 수 있음을 의미한다.

나는 AMD가 서명되지 않은 실행 파일을 다운로드하고 실행할 수 없도록 보장하는 일종의 인증서 검증 (Certificate validation) 기능을 갖추고 있기를 바랐다. 하지만 디컴파일된 코드를 빠르게 살펴본 결과, AutoUpdate 소프트웨어는 그러한 검증을 전혀 수행하지 않으며 다운로드된 파일을 즉시 실행한다는 사실이 드러났다.

이를 발견한 후, 나는 문제가 꽤 심각해 보였기에 AMD에 보고할 가치가 있다고 생각했다.

불행히도, 그들의 버그 바운티 (Bug bounty) 프로그램 이용 약관에는 중간자 (Man-in-the-middle) 공격이 범위 외 (Out of scope)라고 명시되어 있었고, 그에 따라 보고는 종결되었다.

업데이트! 이 내용이 Hacker News에서 화제가 된 지 하루 만에, AMD는 나에게 다시 연락을 취해 결국 이 문제를 조사하겠다고 말했다.

저는 AMD PSIRT에서 연락드립니다. 귀하의 보고서에 대해 여전히 내부 검토를 진행 중입니다. Intigriti가 해당 제출 건을 버그 바운티 (Bounty) 프로그램의 범위를 벗어난 것으로 판단하여 거절했더라도, 저희는 잠재적인 유효성이 있는지 판단하기 위해 세부 내용을 기꺼이 검토하겠습니다.

참고: Intigriti는 AMD가 초기 분류 (Triage)를 위해 사용하는 제3자 버그 바운티 플랫폼이며, PSIRT (Product Security Incident Response Team, 제품 보안 사고 대응팀)는 AMD의 내부 보안 팀입니다.

또한, 그들은 문제를 패치할 때까지 블로그 게시물을 내려달라고 요청했습니다.

이 문제를 다루는 블로그 게시물이 이미 게시되었다는 통보를 받았으며, 이는 프로그램 약관에 부합하지 않는 것으로 보입니다. 게시물을 내려주시고, 저희가 검토를 완료하여 공식 답변을 드릴 때까지 기다려 주시겠습니까?

나는 그렇게 하기로 동의했습니다. 지나고 보니, 그것은 잘못된 선택이었다고 생각합니다.

해당 보고서는 현재의 프로그램 가이드라인에 따라 버그 바운티 지급 대상이 아니므로 범위를 벗어난 것(Out of scope)으로 표시되었습니다. 이는 선택적 도구에 영향을 미치며 MITM (Man-in-the-Middle, 중간자 공격) 시나리오에 의존하기 때문입니다.
추가적인 내부 검토 결과, 저희는 다음과 같이 결정했습니다:
- 이 취약점에 대해 CVE 발행
...

취약점이 패치될 때까지 블로그를 내리기로 동의한 후, 그들은 이 문제가 선택적 도구에 영향을 미치고 MITM이 필요하기 때문에 보상금을 지급하지는 않겠지만, 대신 이 문제에 대해 CVE를 발행하고 저에게 크레딧 (Credit)을 부여하겠다는 상세 내용을 전달하며 후속 조치를 취했습니다.

어떤 공개 일정 (Disclosure timeline)을 따를 계획이신가요?
예: 90 + 30일

나는 그들에게 이 문제에 대해 어떤 공개 기간을 적용할 계획인지 물었습니다. 업계 표준은 90일이며, 다른 연구자들의 기술 보고서 (Write-ups)를 살펴본 결과, AMD 취약점의 대다수가 90일 이내에 해결되었음을 확인할 수 있었습니다.

안녕하세요 @mrbruh님, Ryzen Master 이외의 추가적인 도구들도 영향을 받는 것으로 보여 릴리스 (Release)가 필요하기 때문에, 아마도 더 긴 엠바고 (Embargo)가 필요할 것 같습니다. 더 자세한 내용을 파악하는 대로 계속 업데이트해 드리겠습니다.

요약하자면, 현재 공개(Disclosure) 상황은 다음과 같습니다:

• 그들은 이 취약점이 버그 바운티 (Bug Bounty) 범위를 벗어난다고 선언하면서도, 블로그 게시물이 버그 바운티 규칙을 위반한다는 이유로 게시물을 내려달라고 요청했습니다.
• 단순히 블로그 게시물을 내려달라고 요청했을 뿐만 아니라, 업계 표준에 비해 훨씬 더 긴 기간 동안 게시물을 유지하지 말 것을 요구했습니다.
• 그들은 이 문제가 자사의 여러 소프트웨어 제품에 영향을 미칠 수 있다는 이유로 이러한 연장된 엠바고 (Embargo) 기간을 정당화했습니다. 하지만 패치 자체는 그들이 호스팅하는 XML 파일 내의 http URL에 단 하나의 s를 추가하는 것만큼 간단할 수 있습니다 (따라서 수정하기가 비교적 쉬울 것입니다). - 또한, 만약 이것이 수백만 명의 컴퓨터가 AMD의 여러 제품을 통해 언제든 해킹될 수 있을 만큼 큰 문제라면, 이를 신속하게 수정하는 것이 우선순위가 되어야 하는 것 아닌가요?

결국 저는 추가로 69일을 더 기다렸고, 처음 공개한 시점으로부터 다시 연락을 취하기까지 총 87일이 걸렸습니다.

저는 그들이 이 문제를 해결할 때까지 무기한으로 기다릴 수 없으며, 최초 공개 후 100일이 지나면 제 분석 보고서 (Write-up)를 다시 게시할 계획이라고 그들에게 말했습니다.

AMD는 업데이트를 해주겠다고 확언했음에도 불구하고 저에게 적극적으로 상황을 공유하지 않았습니다. 그들은 엠바고가 끝나기 불과 이틀 전이 되어서야 (그리고 제가 명시적으로 요청한 후에야) 이 취약점에 대한 수정 방법이 무엇인지 알려주었습니다.

여러 개의 선택적 도구들이 이 문제의 영향을 받습니다. 우리는 그중 적어도 하나 이상의 도구가 출시되기를 기다리고 있습니다. 또한, 저희 고객들은 수정 사항이 제공되면 이를 검토하기 위해 추가적인 시간을 요청하고 있습니다. 따라서 고객들에게 추가적인 시간을 제공할 수 있도록 공개를 유보해 주시기를 요청합니다.

그들은 처음에 공개 기간을 명시하지 않은 채 단순히 "더 많은 시간"을 요청했지만, 이틀 뒤 6월 9일에 엠바고를 종료하는 데 동의했습니다.

안녕하세요 @mrbruh님, 6월 9일에 공개할 수 있도록 엔지니어링 팀에 이 과정을 서둘러 달라고 요청했습니다. 계속 업데이트해 드리겠습니다.

저는 최초 공개로부터 총 124일이 지난 시점에 이 업데이트된 보고서를 게시할 계획입니다.

AMD가 몇 개의 HTTP URL에 's'를 추가하게 만드는 데 124일이나 걸리다니!

반전 (The Kicker)

AMD가 이 문제를 해결하기 위해 어떤 패치(patch)를 만들어냈는지는 이제 중요하지 않다고 생각합니다.

제 원문 게시물의 Hacker News 스레드에 올라온 링크에 따르면, 자동 업데이트 프로그램(auto updater)은 완전히 별개의 두 번째 이유 때문에 완전히 망가져 있는 상태입니다.

그들은 어느 시점에 소프트웨어 패키지 목록을 호스팅하는 위치를 ati.com에서 drivers.amd.com으로 변경했습니다.

웹 브라우저에서 XML URL을 열면 자동으로 새 도메인으로 리다이렉션(redirection)됩니다. 하지만 AutoUpdater 프로그램은 이 리다이렉션을 처리할 수 없어서, 프로그램이 충돌하거나 멈춰버립니다.

기묘하게도 상황이 꼬여버린 결과, 제가 발견한 취약점은 실제로 익스플로잇(exploit)이 불가능하다는 것을 의미하는 것 같습니다. 왜냐하면 AutoUpdater가 완전히 망가지기 전에 해당 코드 섹션에 도달조차 하지 못하기 때문입니다.

이는 일종의 진퇴양난(Catch-22) 상황을 초래합니다. 취약점을 수정하려면 업데이트 프로그램을 업데이트해야 하지만, 리다이렉션 버그가 수정될 때까지는 업데이트 프로그램이 업데이트되지 않습니다. 참 대단하네요.

만약 AMD 소프트웨어를 설치하여 사용 중인 사용자라면, 모든 것을 완전히 삭제한 다음 웹사이트에서 새 버전을 내려받을 것을 강력히 권장합니다.

최종 업데이트: 엠바고(embargo)가 끝나기 며칠 전(그리고 제가 이 블로그 포스트의 대부분을 작성한 후), AMD는 이 취약점에 대한 자신들의 패치 내용이 무엇인지 저에게 알려주었습니다:

안녕하세요 @mrbruh님, Ryzen Master의 경우, 자동 업데이트(auto-updater) 기능이 설치 프로그램(installer)에서 제거되어 애플리케이션 계층(application layer)으로 이동되었습니다.
애플리케이션 내의 모든 업데이트 통신은 HTTPS를 사용하여 보안이 유지되며, 업데이트 시 서명 검증(signature verification)을 거칩니다.

저는 이후 해당 주장들을 검증했습니다. 그들이 이제 HTTPS를 완전히 사용하는 것은 사실이지만, 서명 검증에 대한 주장은 사실이 아닙니다. 그들은 다운로드된 실행 파일에 대해 CRC-32 체크만 수행할 뿐이며, 이는 암호학적으로 안전하지 않습니다.

후원 (Donations)

지금까지 제가 Google, ASUS, AMD, TP-Link, MSI (등)에 보고한 취약점들에 대해 지급받은 금액은 총 0달러입니다. 만약 AMD의 취약점이 범위 내(in scope)로 간주되었다면 약 10,000 USD를 지급받았을 것입니다.

이 글이 흥미롭거나 유용했다면, 제 KoFi를 통해 커피 한 잔을 후원해 주실 수 있습니다: https://ko-fi.com/mrbruhh

타임라인 (일/월/년)

• 27/01/2026 - 취약점 발견 (본인)

• 06/02/2026 - 취약점 보고

• 06/02/2026 - 취약점이 수정 안 함/범위 외 (won't fix/out of scope)로 종결됨

• 06/02/2026 - 블로그 게시

• 07/02/2026 - AMD가 입장을 번복하며 결국 검토하겠다고 밝힘

• 09/06/2026 - 취약점에 대한 엠바고 (Embargo)가 124일 만에 종료됨