AMD가 '안 고치겠다'고 한 원격 코드 실행 취약점, 결국 공개됐어요

보안 연구자 MrBruh가 AMD 제품에서 찾아낸 원격 코드 실행(RCE) 취약점의 전말을 블로그에 공개했어요. 제목이 모든 걸 말해주는데요. 'AMD가 고치지 않으려 했던 RCE'. 취약점을 발견해서 제보했는데 벤더가 수정하지 않겠다고 해서, 결국 그 과정 전체를 공개해버린 거예요. 취약점 자체도 자체지만, '제보했는데 안 고쳐주면 어떻게 해야 하나'라는 보안 업계의 오래된 딜레마를 다시 꺼내든 사건이라 같이 짚어볼게요.

RCE가 뭐길래 최고 등급 취약점일까요

RCE는 Remote Code Execution, 원격 코드 실행의 줄임말이에요. 이게 뭐냐면, 공격자가 피해자의 컴퓨터를 직접 만지지 않고도 원격에서 자기가 원하는 코드를 실행시킬 수 있다는 뜻이에요. 비유하자면 도둑이 창문을 깨고 들어오는 수준이 아니라, 우리 집 마스터키를 복사해 가는 상황인 거죠. 일단 코드 실행이 가능해지면 정보 탈취, 랜섬웨어 설치, 내부망의 다른 시스템으로의 침투까지 전부 이어질 수 있어서, 취약점 심각도를 매기는 CVSS 점수에서도 RCE는 보통 최상위권을 받아요. 그래서 보안 업계에서는 RCE 소식이 들리면 '얼마나 쉽게 터지는가'와 '얼마나 많은 기기가 영향을 받는가'부터 따져보게 돼요.

제보했는데 왜 안 고쳐줄까요

보안 취약점을 발견하면 보통 '조율된 공개(coordinated disclosure)'라는 절차를 따라요. 발견자가 벤더에 비공개로 제보하고, 90일 정도 패치할 시간을 준 뒤, 패치가 나오면 상세 내용을 공개하는 방식이죠. 구글의 프로젝트 제로가 이 90일 룰을 업계 표준처럼 만들었고요. 문제는 벤더가 '안 고치겠다'고 답하는 경우예요. 이유는 다양해요. 지원이 끝난(EOL) 제품이라서, 버그바운티 프로그램의 범위 밖이라서, 혹은 '실제 악용 조건이 까다로워 위험도가 낮다'고 자체 평가해서. 벤더 입장에서는 합리적인 판단일 수 있지만, 사용자 입장에서는 위험이 있는지도 모른 채 제품을 계속 쓰게 되는 거죠. 그래서 연구자들은 이런 경우 공개를 선택해요. 공개 자체가 목적이 아니라, 사용자에게 위험을 알리고 벤더를 움직이게 만드는 마지막 수단인 거예요. 이번 건도 정확히 그 패턴이고, 구체적인 공격 체인은 원문에 단계별로 정리돼 있으니 보안에 관심 있는 분이라면 원문을 직접 읽어보시길 권해요.

사실 AMD는 전례가 있어요

2024년의 Sinkclose 취약점을 기억하시는 분이 있을 거예요. SMM이라고, 운영체제보다도 깊은 권한 레벨에서 동작하는 시스템 관리 모드의 결함이었는데요. 당시 AMD는 구형 라이젠 3000 데스크톱 CPU에는 패치를 제공하지 않겠다고 했다가, 커뮤니티의 거센 반발에 입장을 바꿔 결국 패치를 내놨어요. 이번 건과 묶어서 보면 패턴이 보이죠. 기술력과는 별개로, 하드웨어 회사들의 소프트웨어 보안 대응 체계가 소프트웨어 회사들만큼 성숙하지 못한 경우가 많다는 거예요. CPU나 GPU를 파는 회사지만 실제로는 드라이버, 펌웨어, 각종 관리 유틸리티까지 거대한 소프트웨어 스택을 함께 배포하고 있는데, 그 부분의 보안 프로세스가 본업만큼의 대접을 못 받는 거죠.

우리가 챙겨갈 교훈

사용자 입장에서는 할 일이 단순해요. 드라이버와 펌웨어를 최신으로 유지하고, 메인보드나 노트북에 딸려온 잘 안 쓰는 번들 유틸리티는 지워버리는 게 좋아요. 이런 관리용 소프트웨어들이 높은 권한으로 상시 실행되면서 공격 통로가 되는 경우가 정말 많거든요. 만드는 사람 입장에서는 더 중요한 교훈이 있어요. 여러분의 서비스에 취약점 제보가 들어왔을 때 회사가 어떻게 반응하는지가 곧 그 회사의 보안 수준이에요. 제보 창구(security.txt 파일이나 취약점 신고 프로그램)를 열어두고, 제보자를 적이 아니라 무료로 일해준 외부 감사자로 대하는 것. 이번 사례처럼 '안 고치겠다'는 답변은 결국 평판과 비용 양쪽에서 더 비싸게 돌아온다는 걸 기억할 필요가 있어요.