AMD, 치명적인 자동 업데이트 취약점 패치 후 연구원의 10,000달러 버그 바운티 지급 거부

AMD는 보안 연구원의 노력과 협력에도 불구하고 해당 연구원에게 10,000달러의 버그 바운티 (Bug Bounty) 지급을 거부했습니다. 이 매체의 독자라면 얼마 전 AMD의 자동 업데이트 소프트웨어에서 중간자 공격 (Man-in-the-middle attack, MITM)을 통한 잠재적인 원격 코드 실행 (Remote Code Execution, RCE) 취약점을 진단한 보안 연구원에 관한 기사를 기억하실 수도 있습니다. 연구원인 Paul은 AMD의 버그 바운티 프로그램 웹사이트에 보고서를 제출하며, RCE급 버그에 대한 수정과 보상금을 모두 기대했습니다. 하지만 MITM 공격은 프로그램의 정책 범위에 포함되지 않는다는 이유로 보고서가 거절되었습니다. 그럼에도 불구하고 Paul은 AMD의 요청에 따라 해당 상황을 설명하는 블로그 게시물을 내렸습니다. 현재 그 게시물은 다시 온라인에 올라왔으며, 이 모든 상황은 한두 번의 '페이스팜 (Facepalm, 황당함의 표현)'을 유발할 만합니다.

먼저 좋은 소식은 다음과 같습니다. 업데이트 프로그램은 이제 보안이 확보된 것으로 보이며, AMD 소프트웨어 팩의 최신 버전을 다운로드한다면 수정된 버전을 받게 될 것입니다. 하지만 이 과정은 결코 순탄치 않았으며, Paul은 오늘날까지도 자신의 노력에 대해 단 한 푼도 받지 못한 것으로 보입니다. 이는 Microsoft의 Nightmare-Eclipse 관련 문제들을 기준으로 본다면 점점 흔해지고 있는 이야기입니다. 만약 AMD가 문제의 심각성을 완전히 인정했다면, RCE 버그는 10,000달러의 가치가 있었을 것입니다.

업데이트된 게시물에는 전체 이야기가 다음과 같이 담겨 있습니다: 지난 2월, AMD가 Paul에게 블로그 게시물을 일시적으로 내릴 것을 요청했을 때, 회사는 표준 CVE를 발행하고 소프트웨어를 수정하며 해당 발견 내용을 그에게 귀속시키겠다고 말했습니다. 다만 보상금 지급은 불가능하다는 조건이었습니다. Paul은 이에 동의했지만(지금은 후회하는 결정입니다), AMD가 어떤 타임라인을 따를 것인지 물으며 그가 공개적으로 다시 게시물을 올리기 전까지 업계 표준인 90일의 기간을 제안했습니다.

AMD는 "Ryzen Master 외에 추가적인 도구들도 영향을 받은 것으로 보이며, 해당 도구들의 릴리스(release)가 필요하기 때문에 아마도 더 긴 엠바고(embargo) 기간이 필요할 것"이라고 답변했습니다. 이 발언은 여러 면에서 흥미로웠습니다. 첫째, 코드에서 "http"를 "https"로 바꾸는 단 한 글자의 수정만으로 보임에도 불구하고, 왜 AMD가 이를 공개하는 데 그렇게 오랜 시간이 필요한지에 대한 의문을 제기합니다. 둘째, 만약 이 문제를 해결하는 데 그렇게 긴 시간이 필요할 정도로 심각한 문제였다면, 폴(Paul)의 작업은 보상을 받을 가치가 있다고 주장할 수 있습니다. 셋째, 폴이 지적했듯이, 이 문제가 이토록 시급해 보였다면 왜 더 높은 우선순위를 갖지 않았느냐는 점입니다.

그럼에도 불구하고 그는 결국 100일의 기간에 동의했으며, 약속된 시간이 다 가기 전 AMD에 "무슨 일인가요?(wassup?)"라고 물었으나, 다시 추가 시간을 요청받았습니다. "여러 도구가 [해당 버그]의 영향을 받고 있으며", "[AMD의] 고객들이 [수정 사항이] 제공되면 추가 시간을 요청한다"는 답변을 들었습니다. 결국 AMD는 6월 9일에 수정 사항이 준비될 것이라고 연락해 왔으며, 이는 최초 발견 이후 총 124일이 경과한 시점이었습니다.

긍정적인 면을 보자면, AMD는 자동 업데이트 도구(autoupdater) 내의 다운로드 코드를 완전히 재설계한 것으로 보이며, 폴은 새 버전이 실제로 드라이버를 안전하게 다운로드한다는 것을 확인했습니다. 다만 그는 해당 소프트웨어가 다운로드된 파일의 유효성을 검사할 때, 더 이상 암호학적으로 안전하다고 간주되지 않는 오래된 CRC32 해시(hash)를 사용하고 있다고 언급했습니다.

하지만 여기서 아이러니가 발생합니다. 한 레딧(Reddit) 사용자에 따르면, 폴이 발견한 버그는 어차피 트리거(trigger)되지 않았을 가능성이 높다고 합니다. 코드의 관련 섹션이 애초에 호출되지 않고 있었기 때문이며, 이는 업데이트 도구 자체가 고장 나 있었음을 의미합니다. 즉, 업데이트 코드가 업데이트를 할 수 없어서 AMD가 업데이트 도구를 업데이트할 수 없었기에, 사용자들을 위해 새로 다운로드해야 하는 상황이었던 것입니다. *Quis renovatorem renovat(누가 혁신가를 혁신하는가)*라는 말이 정말 딱 들어맞는 상황입니다.

Tom's Hardware의 최신 뉴스 및 심층 리뷰를 이메일로 직접 받아보세요.

Tom's Hardware를 Google 뉴스에서 팔로우하거나, 즐겨찾는 소스로 추가하여 최신 뉴스, 분석 및 리뷰를 피드에서 받아보세요.

Bruno Ferreira는 Tom's Hardware의 기고가입니다. 그는 개발자로서의 경력과 더불어 PC 하드웨어 및 다양한 잡화 분야에서 수십 년의 경험을 보유하고 있습니다. 그는 세부 사항에 집착하며, 자신이 좋아하는 주제에 대해 길게 이야기하는 경향이 있습니다. 그렇지 않을 때는 주로 게임을 즐기거나, 라이브 음악 공연 및 페스티벌에 참여하곤 합니다.