리눅스 Zoom 클라이언트가 사용자 조작 없이 X11 클립보드를 읽는다는 관찰

리눅스용 Zoom 클라이언트가 사용자가 복사나 붙여넣기를 하지 않은 상태에서도 X11 클립보드를 읽는다는 관찰이 나왔다. PuTTY를 만든 Simon Tatham이 Mastodon을 통해 리눅스 Zoom 클라이언트 업데이트 이후 이런 동작을 확인했다고 알리면서 알려진 사례다. 그가 이 사실을 알아챌 수 있었던 것은 X11 클립보드의 동작 방식 때문이다.

X11에서 클립보드는 데이터를 보관하는 중앙 저장소가 아니다. 복사한 애플리케이션이 해당 selection의 소유자가 되어 값을 들고 있고, 다른 애플리케이션이 붙여넣기를 시도할 때 X 서버를 거쳐 소유자에게 데이터를 요청하는 구조다. 즉 클립보드를 읽는 쪽이 있으면 소유한 쪽에서 그 요청을 관찰할 수 있다. Tatham이 포착한 것은 사용자 입력 없이 발생한 이런 읽기 요청이다.

문제의 핵심은 X11에 클립보드 접근을 통제하는 권한 모델이 없다는 점이다. 같은 디스플레이에 연결된 클라이언트라면 누구든 CLIPBOARD selection을 요청할 수 있고, 사용자에게 허용 여부를 묻는 절차도 없다. 클립보드 관리자나 입력기, 스크린샷 도구처럼 정당한 목적으로 상시 읽기를 하는 프로그램도 많지만, 구조적으로는 악의적인 프로세스와 구분되지 않는다.

Wayland는 이 지점에서 설계가 다르다. 클립보드 접근이 컴포지터를 통해 중개되고, 포커스가 없는 클라이언트의 접근을 제한하거나 별도 프로토콜을 요구하는 식으로 통제할 여지가 있다. 리눅스 데스크톱에서 Wayland 전환이 보안 논의와 자주 묶이는 이유이기도 하다.

원문에는 Zoom이 왜 클립보드를 읽는지에 대한 설명이 없다. 링크 붙여넣기 감지 같은 기능, 클라이언트가 사용하는 UI 프레임워크의 기본 동작, 진단이나 텔레메트리 목적 등 여러 가능성이 거론될 수 있지만 확인된 것은 아니다. 어떤 데이터를 읽었고 어디로 보냈는지도 이 관찰만으로는 알 수 없다.

개발자 입장에서 실무적으로 달라지는 것은 크지 않지만 점검할 거리는 분명하다. 비밀번호 관리자나 CLI 도구가 비밀 값을 클립보드에 복사하는 방식을 쓰고 있다면, X11 세션에서는 그 값이 잠시 동안 다른 프로세스에 노출될 수 있다고 가정해야 한다. 클립보드 자동 지우기 시간을 짧게 잡거나, 민감한 값은 클립보드를 거치지 않는 경로를 마련하는 편이 낫다.

데스크톱 애플리케이션을 만드는 쪽이라면 클립보드 폴링이 정말 필요한 기능인지 다시 따져볼 만하다. 폴링 주기와 읽는 시점을 최소화하고, 읽은 내용이 로그나 분석 이벤트에 섞여 나가지 않도록 확인해야 한다. X11에서는 사용자 동의를 받을 방법 자체가 마땅치 않다는 점도 설계 시 고려 대상이다.

다만 이번 건은 소셜 미디어 게시물 한 건에서 출발한 관찰이다. 영향받는 Zoom 버전, 재현 조건, Zoom 측의 공식 설명은 원문에 담겨 있지 않다. 클립보드를 읽는 동작과 그 내용을 외부로 전송하는 동작은 서로 다른 문제이므로, 후자를 확인하려면 별도의 네트워크 분석이 필요하다. Wayland 세션에서는 접근 방식이 달라 같은 현상이 그대로 나타나지 않을 수 있다.