WebGPU 셰이더 하나로 맥 데스크톱이 멈추지만 애플은 보안 문제가 아니란다

신뢰할 수 없는 웹사이트가 WebGPU 셰이더를 이용해 macOS 데스크톱 전체를 마비시킬 수 있다는 내용이 공개됐다. 사용자가 링크를 한 번 클릭하는 것만으로 그래픽 스택이 멈추고, 데스크톱 UI를 조작할 수 없는 상태에 빠진다. Chrome, Firefox, Safari에서 모두 재현되며, 저자가 테스트한 다른 운영체제에서는 같은 현상이 나타나지 않았다.

공개된 코드는 하나의 작은 파일에 담겨 있다. 핵심은 컴퓨트 셰이더가 같은 vec4f 값을 버퍼에 끝없이 덮어쓰는 busy loop를 돌린다는 점, 그리고 버텍스 셰이더가 그와 동일한 버퍼를 읽는다는 점이다. 컴퓨트 셰이더가 버퍼를 놓지 않으니 버텍스 단계가 진행되지 못하고, 이 정체가 GPU를 쓰려는 다른 프로세스로 번진다. 그중 하나가 WindowServer다. 증상은 일정하지 않아서 마우스 포인터가 움직이기도 하고 멈추기도 하며, 비치볼이 뜨거나 화면 일부에 자홍색 노이즈가 나타나기도 한다. 이 상태에서도 SSH 접속은 정상 동작한다. 다만 WindowServer를 감시하는 워치독이 응답 없음을 감지하면 커널 패닉을 일으켜 결국 재부팅된다.

이런 유형의 공격이 처음은 아니다. 2023년 Imperva의 Ron Masas가 WebGL로 유사한 악성 셰이더인 ShadyShader를 만들었고, 애플은 CVE-2023-40441을 CVSS 6.5(중간)로 등록한 뒤 무한 루프를 탐지하는 입력 검증을 강화했다. 문제는 그 검증이 WebGPU에서는 약하게 작동한다는 것이다. 다만 무한 루프 탐지 자체가 근본적으로 승산 없는 게임이다. 정지 문제 때문에 임의의 셰이더가 끝날지 판별할 수 없으므로, 결국 응답 없는 셰이더를 강제로 선점(preemption)하는 장치가 필요하다. 저자는 테스트한 다른 운영체제들이 이 부분을 제대로 처리한다고 본다.

애플 실리콘의 구조도 배경으로 거론된다. M 시리즈에서는 OS 커널이 GPU를 직접 선점할 수 없고, ASC라는 코프로세서가 GPU 처리를 맡으며 선점 로직은 그 펌웨어 안에 들어 있다. 커널이 개입할 수 있는 지점이 제한적이라는 뜻이다. 이 아키텍처는 Asahi Lina가 정리한 문서에서 더 자세히 다뤄진다.

애플의 대응 과정도 함께 공개됐다. 저자는 7월 27일 애플 보안팀에 이슈를 제보했고, 애플은 곧바로 재현한 뒤 수정하겠다는 의사를 밝혔다. 수정 일정은 기밀로 표시돼 공개되지 않았다. 그런데 8월 26일 애플은 입장을 바꿔 이 보고에서 보안상 영향이 없다고 판단했고 제품 변경으로 이어지지 않았다며, 다른 팀으로 넘겨 개선 검토 대상으로만 다루겠다고 알렸다. 저자는 ShadyShader가 중간 등급 보안 이슈로 분류됐던 전례와 비교하며 이 결정이 다소 의아하다고 적었다.

실무 관점에서 이 사례가 던지는 질문은 명확하다. 브라우저 탭은 프로세스 수준에서 격리되지만, GPU 자원은 그렇지 않다. 사용자가 만든 셰이더나 플러그인을 실행하는 서비스, WebGPU를 쓰는 웹 앱, 웹뷰나 Electron으로 감싼 데스크톱 앱이라면 GPU 점유가 다른 프로세스로 번질 수 있다는 전제를 갖고 있어야 한다. 특히 macOS 사용자를 대상으로 WebGPU 기능을 켤 때는 장시간 실행되는 컴퓨트 작업의 상한을 두는 편이 안전하다.

한계도 분명하다. 저자의 재현 테스트는 Tahoe를 실행하는 M 시리즈 맥북에 한정됐고, 다른 맥에서도 같은 일이 벌어지는지는 확인되지 않았다. 이후 Hacker News 이용자들의 제보를 보면 Max 계열 칩은 완전히 멈추는 경우가 상대적으로 적고 Intel Mac도 덜 취약한 편이라는 관측이 있었다. macOS 이외의 운영체제에서도 탭이 느려지고 버벅이는 현상은 나타날 수 있다. 애플이 이 문제를 보안 이슈로 보지 않는다는 점, 그리고 저자가 WebGPU를 기본 비활성화하는 방식으로는 해결하지 말아 달라고 당부했다는 점도 함께 기억해 둘 만하다.