클립보드를 엿본 것은 누구인가 — Zoom, X11, 그리고 Qt
클립보드를 엿본 것은 누구인가 — Zoom, X11, 그리고 Qt
앱이 클립보드를 몰래 읽었을 때, 책임은 그 앱에 있는가, 아니면 그것을 허용한 플랫폼의 설계에 있는가?
도입
2026년 9월 12일(UTC), 해커뉴스 1면에 「리눅스 Zoom 클라이언트가 X11 클립보드에 쓰이는 모든 것을 선제적으로 읽고 있다」는 글이 올라와 433점을 받았다. 원문은 Simon Tatham이 9월 2일 Mastodon(hachyderm.io)에 남긴 연속 게시물이다.
그의 관찰은 간단하다. 리눅스용 Zoom을 6.6에서 7.1.5로 올린 뒤부터, 누군가 CLIPBOARD 선택 영역(Ctrl+C로 복사하고 Ctrl+V로 붙여넣는 쪽)을 새로 소유할 때마다 Zoom이 즉시 그 소유자에게 붙여넣기 요청을 보낸다는 것이다. 사용자가 아무것도 붙여넣지 않았는데도. Tatham은 비밀번호 관리자가 클립보드를 통해 비밀번호를 전달하는 경우를 직접 언급하며, 클립보드에 흥미로운 비밀을 두는 사람이라면 알아야 할 일이라고 적었다.
이 사건은 두 갈래의 반응을 낳았다. 한쪽은 「Zoom이 또 Zoom 했다」는 반응이고, 다른 쪽은 「X11에서는 원래 누구나 그럴 수 있다, Wayland를 쓰라」는 반응이다. 그런데 한 달 뒤, 세 번째 답이 나왔다. Zoom 측이 원인을 서드파티 라이브러리, 즉 Qt의 버그로 지목한 것이다. 이 글은 세 후보 — 앱, 플랫폼, 라이브러리 — 를 차례로 따져 본다.
현상 분석 — 「원샷 붙여넣기」가 드러낸 것
Tatham이 이 동작을 발견한 경위가 흥미롭다. 그는 「원샷 붙여넣기」 도구를 즐겨 쓴다. 클립보드 소유권을 가져간 뒤 붙여넣기 요청을 정확히 한 번 처리하고 바로 종료하는 프로그램이다. 웹 폼의 여러 칸을 채울 때, 붙여넣을 값을 순서대로 대기열에 걸어 두고 각 칸에서 붙여넣기만 누르면 된다. 그런데 apt 업데이트 이후 이 도구가 시작하자마자 종료되기 시작했다. 디버깅해 보니, 클립보드를 소유하는 순간 Zoom이 붙여넣기 요청을 보내 그 「한 번」을 써 버리고 있었다.
이 관찰이 가능한 이유는 X11 선택 영역(selection)의 구조에 있다. Tatham의 설명에 따르면 X11에서 붙여넣기는 「현재 선택 영역 소유자에게 연락해 데이터를 보내 달라고 요청하는」 방식으로 이루어진다. 해커뉴스의 st_goliath도 같은 점을 짚었다(직접 인용은 아니고, 코멘트의 요지를 요약). 윈도우처럼 중앙 저장소에 데이터가 쌓이는 것이 아니라, 복사한 클라이언트가 데이터를 들고 있고 붙여넣으려는 클라이언트가 그 클라이언트와 X 서버를 통해 대화한다는 것이다. 그래서 원본 프로그램을 종료하면 데이터가 사라지고, 현대 데스크톱 환경은 소유권 변경을 감지해 데이터를 즉시 가져오는 클립보드 관리자 데몬을 따로 둔다.
이 구조에는 부수 효과가 있다. 소유자는 누가 언제 붙여넣는지 알 수 있다. Tatham은 이것을 이용해 붙여넣는 「순간」의 시각을 돌려주는 장난도 가능하다고 적었다. 반대로 말하면, 소유자 측 도구만 있으면 「누가 요청했는가」를 관측할 수 있다. 그는 표준 도구로 재현하는 방법을 남겼다.
sudo apt install xclip
echo -n foo | xclip -selection clipboard -loop 1 -verbose-loop 1은 한 번의 요청을 처리하면 종료하라는 뜻이다. 정상이라면 사용자가 어딘가에 붙여넣을 때까지 기다려야 한다. Zoom 7.1.5가 같은 X 서버에 떠 있으면, 이 명령은 즉시 종료된다.
Tatham의 관찰에서 사실로 확인되는 범위를 정리하면 이렇다. 대상은 CLIPBOARD뿐이고, 마우스 선택 후 가운데 버튼으로 붙여넣는 PRIMARY는 건드리지 않는다. 변경 감지는 XFIXES 확장을 통해 이루어지는 것으로 보인다. 요청을 보낸 창은 Zoom의 메인 창이 아니라 일반적인 이름을 가진 보조 창이었고, 그는 xkill로 그 창을 죽여 어떤 앱이 사라지는지 보고서야 Zoom임을 확인했다고 한다. 그리고 웹 설정에서 클립보드 관련 옵션을 끄고 클라이언트를 재시작해도 동작은 그대로였다.
확인되지 않은 것도 분명히 해 두자. Zoom이 읽어 간 내용을 외부로 전송했는지는 아무도 보여 주지 못했다. Mastodon 스레드의 한 이용자는 클립보드에 데이터를 계속 흘려 넣고 Zoom의 송신 트래픽이 늘어나는지 보자고 제안했고, 다른 이용자는 Zoom 링크를 감지해 회의 참가를 제안하려는 기능일 것이라고 추측했다. 어느 쪽도 이 스레드 안에서 검증되지 않았다. 「읽었다」와 「유출했다」는 다른 주장이다.
심층 분석 — 앱의 문제인가, 플랫폼의 문제인가
해커뉴스 토론의 중심축은 이 질문이었다. Wayland가 해결한다는 쪽의 논리는 이렇다. Mastodon 스레드의 shrub900은 Wayland에서는 일반적으로 키보드 포커스를 가진 앱만 클립보드에 접근할 수 있으므로, 백그라운드의 Zoom은 이런 동작을 할 수 없다고 설명했다(직접 인용은 아니고, 코멘트의 요지를 요약). 실제로 Wayland 코어 프로토콜은 컴포지터가 클라이언트에 키보드 포커스를 주기 「직전」에 현재 선택 영역을 알려 주도록 정하고 있다. 이 규정은 아래에서 다룰 Qt 버그 보고서가 wayland.xml을 인용하며 그대로 옮기고 있다.
반론도 여럿 나왔다. 하나는 우회 경로다. 데스크톱이 Wayland여도 앱은 XWayland 위에서 X11 클라이언트로 돌 수 있고, 그러면 X11 방식으로 클립보드를 다룰 수 있다는 지적이다(dotstdy, 직접 인용은 아니고, 코멘트의 요지를 요약). 다른 하나는 기능 손실이다. Tatham 자신이 물었다. 그렇다면 xclip -o 같은 명령행 붙여넣기 도구도 동작하지 못하는 것 아니냐고. 그는 그런 워크플로를 많이 쓰기에 Wayland로 옮길 때 큰 트레이드오프가 될 것이라고 적었다. 해커뉴스의 teravor는 Wayland에서도 보안 컨텍스트로 특권 프로토콜을 막지 않으면 일반적으로 더 안전하지 않다고 했고, 막으면 앱이 포커스를 얻을 때까지 클립보드를 못 읽거나 포커스를 빼앗으려 짧게 창을 띄우는 시도가 눈에 띌 것이라고 말했다(직접 인용은 아니고, 코멘트의 요지를 요약). bandrami는 그런 능력의 차단이 Wayland가 만들어진 이유 중 하나였지만, 사람들이 원하던 기능까지 없앤 결과 컴포지터들이 원래의 결함을 다시 복제하고 있다고 꼬집었다(직접 인용은 아니고, 코멘트의 요지를 요약).
이 논쟁을 정리하면, Wayland는 클립보드 접근을 「불가능」하게 만든 것이 아니라 「포커스라는 시점」에 묶었다. 이는 공격 창을 좁히지만 닫지는 않는다. 그리고 클립보드 관리자나 원샷 붙여넣기 도구처럼 포커스 없이 클립보드를 다뤄야 하는 정당한 도구를 위해 별도의 데이터 제어 프로토콜이라는 뒷문이 다시 열린다. 「누가 그 뒷문을 쓸 자격이 있는가」를 판정하는 기준이 앱 단위 권한 체계가 아니라면, 문제는 형태만 바꿔 남는다.
X11 쪽의 한계는 더 근본적이다. Tatham은 9월 12일의 답글에서 클립보드 접근을 앱별로 막는 방어가 왜 어려운지 설명했다. X11 프로토콜에서는 붙여넣기를 요청한 클라이언트를 창 ID 범위로 식별하기는 쉽다. 하지만 그것이 「어떤 앱인가」를 확정하기는 어렵다. 범위 안에서 제목이나 WM_COMMAND 같은 식별 정보를 가진 메인 창을 찾는 일이 자명하지 않고, 무엇보다 창과 속성 어디에도 위조 불가능한 것이 없다. 그래서 그는 이런 방어가 「대충 만든」 앱에는 통할 수 있어도, 진짜 악의를 가진 앱은 신원을 속일 수 있다고 가정해야 한다고 결론지었다.
여기서 이번 사건의 성격이 드러난다. X11의 신뢰 모델은 같은 X 서버에 붙은 모든 클라이언트를 같은 신뢰 수준으로 다룬다. 선택 영역을 읽는 것은 「무례하지만 허용된」 일이다. 따라서 X11 위에서 이 동작은 플랫폼이 막지 못하는 것이 아니라, 애초에 막을 대상으로 정의되지 않은 것이다. 이 관점에서 보면 「Zoom의 문제냐, 플랫폼의 문제냐」는 양자택일이 아니다. 플랫폼이 경계를 두지 않으면, 경계는 각 앱의 자제력에 위임된다. 그리고 앱의 자제력은 그 앱이 쓰는 라이브러리의 기본 동작에 다시 위임된다.
그 마지막 위임이 이번 사건의 결말이었다. 10월 8일, 해커뉴스 스레드에 tommygaessler라는 계정이 Zoom 측 입장을 전했다(직접 인용은 아니고, 코멘트의 요지를 요약). Zoom Workplace for Linux가 X11 클립보드에 예상보다 자주 접근하는 버그를 인지하고 있었고, 원인이 된 서드파티 라이브러리를 찾아 그 메인테이너와 해결했으며, 수정이 9월 18일 배포된 7.2.0에 포함되었다는 내용이다. 그가 링크한 것은 Qt의 QTBUG-149610이다. 이 계정이 Zoom의 공식 대변인인지는 HN 코멘트만으로 확인할 수 없다는 점은 적어 둔다.
QTBUG-149610은 8월 29일에 등록되었다. 제목은 「TextInput canPaste가 QClipboard::dataChanged()에서 즉시 재계산된다」이다. 보고서에 따르면 Qt Quick의 QQuickTextInput은 클립보드가 바뀔 때마다 「붙여넣기 가능 여부(canPaste)」를 다시 계산하는데, 한 변경(6c07e2a762) 이후 빈 클립보드를 제외하려고 QMimeData::text()를 호출하게 되었다. 형식만 확인하는 hasText()와 달리 text()는 클립보드의 「내용」을 실제로 전송받는다. 이 회귀는 Qt 6.10.3과 6.11.0부터 포함되었다고 보고서는 적는다. 보고서의 주된 서술은 Wayland에서 포커스를 얻을 때마다 내용 전송이 일어나 최대 약 2초 UI가 멈추는 성능 문제다. X11에서 Tatham이 본 「소유권이 바뀔 때마다의 즉시 요청」이 같은 경로라는 것은 Zoom 측 주장과 메커니즘의 일치에서 나온 추론이며, Zoom이 사용하는 Qt 버전을 이 글에서 직접 확인하지는 못했다.
이 보고서에서 눈에 띄는 대목이 두 가지 있다. 첫째, 9월 10일 한 참여자가 이것은 성능 문제를 넘어 보안·프라이버시 문제이며, TextInput이 있는 Qt Quick 앱이 여러 곳에서 악성코드로 간주될 수 있다고 지적했다. 둘째, Wayland에서도 이 회귀는 「포커스를 얻는 순간마다」 내용을 읽었다. 즉 Wayland의 포커스 제한은 읽는 시점을 좁혔을 뿐, 읽을 이유가 없는 내용을 읽는 코드 자체를 막지는 못했다.
전망과 시사점
이 사건이 보여 주는 첫 번째 교훈은 「의도」와 「결과」의 분리다. Zoom의 설명이 사실이라면, 어떤 제품 관리자도 비밀번호를 수집하라고 지시하지 않았다. 텍스트 입력란 하나가 붙여넣기 버튼을 활성화할지 판단하려고 클립보드 내용 전체를 가져온 것이다. 하지만 사용자 입장에서 결과는 같다. 비밀번호 관리자가 클립보드에 올린 비밀이 회의 앱 프로세스의 메모리에 들어갔다. 프라이버시 사고의 상당수는 악의가 아니라 「편의를 위한 기본값」에서 나온다.
두 번째는 책임의 사슬이다. X11은 경계를 두지 않았고, Qt는 회귀를 넣었고, Zoom은 그 Qt를 그대로 출하했다. 각 단계는 자기 몫의 변명을 가진다. X11은 오래된 신뢰 가정을 따랐을 뿐이고, Qt는 성능 회귀로 분류된 버그를 고쳤고, Zoom은 서드파티 라이브러리 탓을 했다. 그러나 사용자에게 보이는 것은 「Zoom」이라는 이름뿐이다. 해커뉴스와 Mastodon 반응의 상당수가 과거 Zoom의 macOS 권한 문제나 로컬 웹 서버 사건을 끌어오며 신뢰를 거둔 것도 그래서다. 라이브러리 버그라는 설명은 기술적으로 타당할 수 있지만, 출하한 쪽의 검증 책임을 지우지는 않는다.
세 번째는 리눅스 데스크톱의 권한 모델이다. 해커뉴스의 amelius와 Lucasoato는 휴대폰은 수년 전부터 더 나은 권한 체계를 가졌는데 리눅스 배포판은 왜 앱을 제대로 샌드박스하지 않느냐고 물었다(직접 인용은 아니고, 코멘트의 요지를 요약). ryandrake는 더 나아가, 오늘날의 클립보드 개념이 새로 발명된다면 가장 관대한 프라이버시 리뷰도 통과하지 못할 것이라고 주장했다(직접 인용은 아니고, 코멘트의 요지를 요약). 실무적 대응으로는 브라우저 탭에서 Zoom 웹 클라이언트를 쓰는 방법, Qubes OS처럼 VM으로 격리하는 방법, iPad 같은 별도 기기를 쓰는 방법이 언급되었다. 브라우저는 클립보드 읽기를 사이트별 권한으로 다루므로, 역설적으로 데스크톱 네이티브 앱보다 경계가 선명하다.
(9월 13일 이후 추기: Qt의 수정은 9월 13일 dev와 6.12 브랜치에, 9월 15일 6.11 브랜치에 통합되었다. 6.8 백포트 요청에 대해 담당자는 공개 6.8 브랜치에는 이 회귀가 없다고 답했고, 10월 7일 상용 LTS 6.8 브랜치에도 관련 변경이 통합되었다는 기록이 남았다. Zoom 7.2.0의 9월 18일 배포는 HN 코멘트의 주장이며, 이 글에서 릴리스 노트로 확인하지는 않았다.)
결론
「Zoom의 문제인가, 플랫폼의 문제인가」라는 질문에 대한 답은 「둘 다이고, 그 사이에 라이브러리가 있다」이다. X11은 같은 서버의 모든 클라이언트가 선택 영역을 읽을 수 있게 설계되었고, 앱을 신뢰할 수 있게 식별할 수단도 주지 않는다. 그 위에서는 프라이버시가 각 앱과 그 앱이 쓰는 툴킷의 자제력에 맡겨진다. 이번에는 Qt의 한 줄짜리 회귀가 그 자제력을 무너뜨렸다.
Wayland는 이 문제를 포커스 시점으로 좁히지만, 같은 Qt 회귀가 Wayland에서도 포커스마다 클립보드 내용을 읽었다는 사실은 프로토콜만으로 충분하지 않음을 보여 준다. 그리고 이 사건을 발견한 것은 보안 감사가 아니라, 한 개발자가 직접 만든 원샷 붙여넣기 도구가 이상하게 일찍 끝났다는 사소한 관찰이었다.
당신의 비밀번호 관리자는 클립보드를 거쳐 비밀번호를 건네고 있는가. 그렇다면 지금 같은 데스크톱에 떠 있는 앱 중 몇 개가, 어떤 라이브러리 버전으로, 그 순간 클립보드에 손을 뻗을 수 있는지 알고 있는가.
출처: