AMD가 고치지 않을 RCE

출처: Hacker News

새로운 게이밍 PC에서 주기적으로 뜨는 성가신 콘솔 창 때문에 여러 번 방해를 받던 중, 그 실행 파일이 AMD의 AutoUpdate 소프트웨어라는 것을 찾아냈습니다.

분노에 찬 저는 이 소프트웨어를 역컴파일해서 작동 방식을 파악하고 싶었고, 그 과정에서 사소한 원격 코드 실행(RCE) 취약점을 우연히 발견했습니다.

먼저 찾은 것은 업데이트 URL이 프로그램의 app.config에 저장돼 있다는 점이었습니다. 운영 환경에서 “Development” URL을 사용한다는 점은 다소 이상하지만, HTTPS를 사용하므로 안전합니다.

문제는 이 .xml URL을 웹 브라우저로 열어보면, 모든 실행 파일 다운로드 URL이 HTTP를 사용하고 있다는 점입니다.

즉, 네트워크 상의 악의적인 공격자나 ISP에 접근 권한이 있는 국가 차원의 공격자는 손쉽게 MITM(중간자) 공격을 수행해 응답을 임의의 악성 실행 파일로 바꿀 수 있습니다.

AMD가 서명되지 않은 실행 파일을 다운로드·실행하지 못하도록 인증서 검증을 수행할 것이라 기대했지만, 역컴파일한 코드에서는 AutoUpdate 소프트웨어가 전혀 검증을 하지 않고 다운로드된 파일을 바로 실행한다는 사실을 확인했습니다.

이 사실을 AMD에 보고했지만, 버그 바운티 프로그램의 이용 약관에 “중간자 공격”은 범위 밖이라고 명시돼 있었고, 따라서 보고서는 그 이유로 폐쇄되었습니다.

업데이트! 이 글이 Hacker News에서 화제가 된 지 하루 만에 AMD가 다시 연락을 주었고, 결국 이 사안을 조사하겠다고 답했습니다.

AMD PSIRT에서 메일을 드립니다. 현재 귀하의 보고서를 내부 검토 중입니다. Intigriti가 바운티 프로그램 범위 밖이라고 판단했더라도, 우리는 여전히 세부 내용을 검토하여 잠재적인 유효성을 판단하고자 합니다.

Note: Intigriti는 AMD가 초기 심사를 위해 사용하는 제3자 버그 바운티 플랫폼이며, PSIRT(제품 보안 사고 대응팀)는 AMD 내부 보안 팀입니다.

또한, AMD는 제가 문제를 해결할 때까지 블로그 글을 삭제해 달라고 요청했습니다.

이 이슈에 대한 블로그 글이 이미 공개된 것으로 확인되었습니다. 이는 프로그램 약관에 부합하지 않는 것으로 보입니다. 검토가 완료되고 공식 답변을 드릴 때까지 글을 삭제해 주시겠습니까?

저는 요청에 동의했지만, 뒤돌아보면 이는 잘못된 선택이었음을 인정합니다.

해당 보고서는 현재 프로그램 가이드라인에 따라 현금 보상 대상이 아니며, 선택적 도구에 영향을 주고 MITM 시나리오에 의존한다는 이유로 범위 밖으로 처리되었습니다.

내부 검토 결과, 우리는 다음과 같이 진행하기로 했습니다.

- 이 취약점에 대한 CVE 발급
- 패치 적용
- 보안 연구원에게 인정 제공

블로그를 내리겠다는 약속을 한 뒤, AMD는 저에게 보상을 지급하지 않을 것이며 대신 CVE를 발급하고 크레딧을 제공하겠다고 통보했습니다.

어떤 공개 일정(Disclosure Timeline)을 적용하실 계획인가요?

예: 90 + 30일

제가 공개 일정에 대해 물었을 때, 업계 표준은 90일이며 대부분의 AMD 취약점은 90일 이내에 해결된다는 점을 언급했습니다.

안녕하세요 @mrbruh, Ryzen Master 외에도 영향을 받는 도구가 있어 더 긴 embargo가 필요할 것 같습니다. 진행 상황을 지속적으로 알려드리겠습니다.

요약하면 현재 공개 상황은 다음과 같습니다.

• 바운티 대상이 아니라는 이유로 범위 밖으로 처리했지만, 규칙 위반이라 블로그 글을 삭제해 달라고 요구했습니다.
• 블로그 삭제를 요구할 뿐 아니라, 업계 표준보다 훨씬 긴 embargo(공개 보류 기간)를 요구했습니다.
• 이 기간이 길어진 이유는 여러 소프트웨어에 영향을 미칠 수 있다고 했지만, 실제로는 XML 파일의 http URL에 s 하나만 추가하면 해결될 정도로 간단한 패치였습니다.
• 수백만 대의 컴퓨터가 언제든 해킹당할 수 있는 심각한 이슈라면, 신속히 패치하는 것이 우선이 되어야 하지 않을까요?

저는 추가로 69일을 더 기다려 총 87일이 지난 시점에 다시 연락했습니다. “무한정 기다릴 수는 없으니, 최초 공개 100일이 지나면 다시 글을 공개하겠다”고 통보했습니다.

AMD는 약속대로 진행 상황을 알려주지 않았고, embargo 종료 직전(제가 명시적으로 요청한 뒤)야 겨우 패치 내용을 알려주었습니다.

여러 선택적 도구가 영향을 받으며, 최소 하나는 아직 릴리즈를 기다리고 있습니다. 또한 고객들은 패치가 제공된 후 검토할 시간을 요구하고 있습니다. 따라서 공개를 보류해 고객에게 추가 시간을 제공해 주시길 바랍니다.

초기에는 “추가 시간이 필요하다”고만 했고 구체적인 공개 일정은 제시하지 않았습니다. 그러나 이틀 뒤, 6월 9일에 공개하겠다고 최종 일정을 잡았습니다.

안녕하세요 @mrbruh, 엔지니어링 팀에 빠르게 진행하도록 요청했으며 6월 9일에 공개할 수 있도록 하겠습니다. 진행 상황을 계속 알려드리겠습니다.

저는 초기 공개 후 124일이 된 시점에 이 업데이트된 글을 공개할 예정입니다.

124일 만에 AMD가 HTTP URL에 ‘s’를 하나 추가하도록 만든 셈!

The Kicker

패치를 어떻게 적용했는지는 크게 중요하지 않을 것 같습니다.

원 글의 Hacker News 스레드에 올라온 링크에 따르면, AutoUpdater 자체가 두 번째, 전혀 무관한 이유 때문에 완전히 망가졌다고 합니다.

AMD는 한때 ati.com에 소프트웨어 패키지 목록을 호스팅했지만, 어느 순간 drivers.amd.com으로 옮겼습니다. XML URL을 브라우저에서 열면 자동으로 새 도메인으로 리다이렉트되지만, AutoUpdater 프로그램은 이 리다이렉트를 처리하지 못해 충돌하거나 멈춥니다.

이런 기묘한 상황 때문에 제가 발견한 취약점은 실제로는 악