StarDict가 X11 클립보드를 원격 서버로 전송함

• StarDict가 X11 환경에서 사용자의 텍스트 선택을 암호화되지 않은 HTTP로 외부 서버에 전송하는 중대한 보안 문제가 발견됨
• 해당 이슈는 YouDao 및 dict.cn 플러그인이 Debian의 기본 설정에서 기본 활성화되어 발생함
• 이 기능은 사용자가 아무 텍스트를 선택하면 자동으로 서버로 전송됨을 의미하고, 민감 정보 유출 위험이 있음
• 패키지 관리자는 기능 비활성화와 플러그인 분리 제안을 검토했으나 근본적인 해결책 적용은 미흡함
• 이 문제는 과거에도 여러 차례 제기됐으나, 완전한 대응 부재 및 보안 의식의 중요성을 다시 드러냄

---

StarDict의 동작 및 보안 이슈 개요

• StarDict는 GPLv3 라이선스의 크로스 플랫폼 사전 프로그램으로, 다양한 언어 지원 및 플러그인 생태계를 보유함
• Debian의 기본 설정에서 StarDict 실행 시, 사용자가 선택한 텍스트가 암호화되지 않은 HTTP를 통해 youdao.com과 dict.cn 두 개의 원격 서버로 전송됨
• 이 문제는 oss-security 메일링 리스트와 Debian 버그 트래커에도 보고됨

문제의 상세 내용

• StarDict 설계상 사전 웹사이트와 통신하는 코드는 자연스러운 구성이나, "** 스캔**" 기능이 기본 활성화되어 있음
  • 이는 사용자가 마우스로 텍스트를 선택하면 자동으로 번역 팝업을 띄우고, 해당 텍스트가 외부 서버로 자동 전송됨을 의미함
  • 사용자가 StarDict를 배경에 항상 실행해둘 때 문제가 심각함

Linux 환경별 차이

• Wayland 환경에서는 StarDict가 타 애플리케이션의 텍스트 캡처 불가, 스캔 기능이 동작하지 않아 보안 문제 발생하지 않음
• 기존 X11 환경에서만 이 문제가 현존함

Debian 및 StarDict 개발자 반응

• Debian 패키지 관리자 Xiao Sheng Wen은 "스캔 기능과 YouDao 플러그인은 비활성화 가능"하다며 큰 문제로 인식하지 않음
• 그러나 보고자인 Vincent Lefevre는 "** 프라이버시 관련 기능은 반드시 비활성화 상태가 기본이어야 함**"이라고 지적
• 패키지 설명을 통해 기능을 알릴 수 있으나, stardict-plugin 설명엔 온라인 사전 사용이 언급되어 있지 않음
• 플러그인 분리 등의 개선책 제안은 있으나, 즉각적 조치는 이뤄지지 않음

기능의 편의성과 보안 우려

• 스캔 기능은 외국어 읽기 시 신속한 사전 조회를 원할 때 StarDict의 주요 장점임
• 하지만 사용자가 해당 통신이 암호화되지 않는다고 예상하기 어려움. 중간 경로의 누구나 민감 텍스트 노출 위험이 있음

과거의 유사 보안 사고와 대처

• 2009년과 2015년에도 유사 사례가 보고됨
  • 2009년: 네트워크 사전 비활성화가 기본값으로 잠시 적용
  • 그러나 2016년 추가된 YouDao 플러그인은 해당 설정을 무시함
  • 2015년 문제는 2025년이 되어서야 플러그인 제거 형태로 해결
• 이처럼 이슈 재발 및 대처 지연, 유지관리자 교체 및 우선순위 미숙이 반복됨

사용자 규모와 보안 영향

• Debian 통계상 현재 약 178명만이 StarDict 설치 이용 중이나, 통계 비참여 시스템 등 감안 시 수년간 많은 사용자가 텍스트 유출 위험에 노출되어 왔을 수 있음
• 비밀번호 복사, 민감 이메일, 문서 편집 중 선택 텍스트 등이 그대로 외부 노출될 가능성 발생

오픈소스 생태계와 보안의제

• Debian처럼 대형 배포판은 수많은 패키지를 관리하며, 업데이트 누락 및 소프트웨어 노후화가 빈번함
• "충분히 많은 사람들이 보면 버그는 얕다"라는 Linus의 법칙도 실제로 누군가 버그를 발견, 보고, 그리고 유지관리자가 문제로 인정 후 수정까지 해야 성립함

X11에서 Wayland로의 변화

• Wayland 도입은 이런 유형의 보안 결함, 특히 애플리케이션 간 정보 유출 가능성 자체를 줄이기 위함임
• 단, 이에 따른 기능적 불편과 새로운 사용 권한 처리 방식도 과제로 남음

결론 및 시사점

• 발견되고 진단, 보고되는 보안 문제가 여전히 미해결로 남거나 재발하는 현실이 우려를 불러옴
• Linux의 보안 평판 유지를 위해서는 오픈소스 개발자, 패키지 관리 담당자, 사용자의 꾸준한 문제 인식과 신속한 대응이 필수임

[GN⁺]

Hacker News 의견

• Xiao가 지적한 것처럼, 소프트웨어를 설치하는 사용자는 패키지 설명을 읽을 수 있고, 실제로 스캔 기능이 언급되어 있음. 하지만 Debian 관리자가 종종 버그 리포트에 대해 “모든(심지어 의존성으로 설치되는 수백 개의) 패키지 설명을 꼼꼼히 읽어야 한다”는 식의 답변을 하는데, 솔직히 몇일 전에 배포된 Trixie 기준으로 모든 설명과 README를 다 읽기 시작했다면 아직도 다 못 읽고 있을 것임

  • “계획서와 철거 명령이 Alpha Centauri 현지 사무실에 당신들 지구 시간으로 오십 년 동안 전시되어 있었음. 지역 사정에 관심을 두지 않으면…” 이 부분이 딱 맞는 느낌임 youtube 영상 링크
  • 이런 식의 답변이 나오면 악의적 의도가 있는 거라고밖에 볼 수 없을 것 같음
  • 나는 Debian 저장소에서 프로그램을 설치할 때, 편리함과 신뢰를 위해서임. 패키지의 동작을 유지보수가 변경할 때 불만이 많긴 하지만, 사람들은 클립보드 정보를 타인에게 보내는 기능을 opt-in, 즉 명확히 활성화할 수 있게 했으면 더 좋았을 것임. 신뢰를 저버리는 행동임
  • Trixie 배포 때 모든 패키지 설명과 README를 다 읽는 게 힘들다는 의견에 동의함. 90년대 후반~2000년대 초반에 Debian을 처음 쓸 때는 dselect로 원하는 패키지 고르고 몇 시간 투자하면 모든 옵션을 실제 하드웨어 환경에 맞게 조정할 수 있었음(이때는 지금처럼 동적이지 않아서 하나하나 옵션 선택해야 했음). 지금은 패키지도 너무 많고, 커널 설정도 지나치게 방대해져서 현실적으로 다 체크할 수 없는 세상임(아직 dselect 쓰는 사람… 있음?)
  • 당신이 말한 걸 동의함. 특히 그 패키지 관리자가 예상치 못한 동작을 여러 번 만들었다는 점에서 예전 문제처럼, 다른 패키지의 설정 파일까지 바꿔버리는 부적절한 행동이 계속 반복되어 왔음. 이런 건 저장소에서 제거해야 함

• 당연히 사전 프로그램이면 웹사이트와 통신하는 코드를 포함하고 있다고 생각할 수도 있음. 하지만 apt-get으로 딕셔너리를 설치하면 내가 딕셔너리 전체를 내 컴퓨터에 다 가지는 걸 기대할 수 있음. 사실 종이 사전도 수백 년간 써왔으니까… Stardict는 온라인 기반이긴 한데, 정상일 수도 있지만 뭔가 함정 같은 느낌임

  • 이건 세대 차이라고 생각함. 지금 앱이 인터넷과 통신하는 게 당연하다고 생각하는 사람은, 로컬에 설치해서 외부와 통신하지 않는 소프트웨어에 익숙하지 않은 젊은 세대임. 개발자 이력 검색해봐도 컴퓨터 과학에 능통한 사람이고, 오프라인 사전이 가능하다는 것도 잘 알고 있지만, 본인 세대의 “당연함”을 따라가는 것 같음. 현재 세상에서 로컬 설치 후 오프라인 데이터로만 동작하는 앱은 마치 기사도 정신처럼, 아주 소수의 IT 돈키호테들이 유지하는 개념이라는 사실이 슬픔
  • 설령 정상이라 해도, 암호화되지 않은 HTTP를 사용하는 건 절대 용납될 수 없는 일임
  • 오래된 ding 프로그램은 로컬 사전을 아주 잘 지원함. Debian에도 포함되어 있음 ding 링크
  • 나도 이 점이 눈에 띄었음. 이런 단순한 기능조차 라이브 서비스로 기대하는 세상이 슬픔
  • 어느 순간부터 gui 앱을 네트워크 접근 없이 실행하기 시작했음. 처음에는 firejail, 그다음엔 bubblewrap, 그리고 시간이 흐르며 만든 bash 스크립트로 샌드박스 환경에서 앱을 돌리고 있음. flatpak 이전부터 쭉 그렇게 해왔음

• 삼성폰에서 모든 클립보드 데이터가 내 삼성 계정의 기기들 전체(비밀번호까지 포함)로 공유되고, 심지어 히스토리까지 남는 걸 알게 되어 꽤 놀랐음. 기본 설정이었는지, 우연히 동의했는지는 기억이 안 남. 이 데이터가 아마 삼성 서버를 경유해 전달되는 걸로 추정됨. 공유 기능은 껐지만, 클립보드 히스토리는 꺼지지 않고, 다른 키보드로 바껴도 삼성 키보드로 다시 전환하면 예전 클립보드 내역이 다 남아있음. 이제 다음 폰은 삼성 선택 안 할 생각임

  • 삼성 TV도 그렇고, 시청기록이나 개인정보를 마케팅 업체와 공유하는 걸로 알고 있음. 삼성 프라이버시 정책은 폰이나 TV 모두 동일함
  • KDE connect를 통해 리눅스에서 복사한 비밀번호가 안드로이드 클립보드 기록에 남는 걸 봤음. 클립보드 공유 전체를 끄지 않고, 암호만 선별해서 옮기지 않도록 막는 방법이 있을지 궁금함
  • Samsung 기기를 쓸 때 삼성 계정 자체를 만들거나 로그인하지 않는 걸 추천함. 그게 기업이 내 데이터 접근할 기회를 확 줄여줌

• Wayland에 대한 얘기가 좀 오해 소지가 있다고 느껴짐. 마지막 요약이 정확함: “어쩌면 StarDict가 Wayland에서 돌아가기 위해 특별 권한을 요청했을 것이고, 사용자는 지금 그렇듯 그 기본값을 그대로 수락했을 것임.” 즉, 그럴 가능성이 크고, 설치 과정에서 자동으로 그 권한을 지정해놨을 수도 있음. 악성코드는 언제나 존재함. Wayland가 어떤 공격을 방어해줄 순 있지만, 배포판 일부로 설치된 패키지로부터는 안전하지 않음

  • 오해가 아니라 Wayland가 Xorg 대비 해당 측면에선 확실히 나음. 그러나 문제의 본질은 이것보다 더 구조적인 부분임. 예를 들면 전송되는 데이터가 암호화조차 안 되어 있었음! StarDict는 X11에서, Debian 기본 설정만으로 사용자가 선택한 텍스트를 HTTP로 두 개의 원격 서버로 보내버림. 패키지 설명이나 YouDao 플러그인을 잘 읽어봤다 해도, 최소한 통신이 암호화되어 있을 걸 기대할 수 있음. 그러나 실제로는 dict.youdao.com과 dict.cn 서버에, 아무런 보안 없는 HTTP로 데이터를 보내는데, 이 경로에 있는 누구라도 요청 내용을 볼 수 있음

• 클립보드마다 로컬 사전 질의는 괜찮음. 원격 사전 요청 기능 추가도 문제 없음. 이 두 기능을 쉽게 조합하는 것도 특수 플래그 같은 걸로 분리했다면 납득할 만했지만, 이 두 기능을 기본값에서 섞어서 쓰는 건 거의 악의적인 행동에 가까움

  • 여기서 얘기하는 youdao는 번역 서비스임. 오프라인 번역은 온라인 번역에 비해 한참 못함, 즉 나는 데이터가 없을 때에만 local google offline translation 패키지 같은 걸 쓰고 싶을 뿐임. Stardict는 안 쓰지만, 단순히 단어 뜻 말고 더 많은 번역을 하려면 그런 동작이 충분히 예상 가능함. 결론적으로 이 기사 전체 요점은 “중국 번역 프로그램이 클립보드 데이터를 자기 웹사이트와 중국 번역 서비스로 보냈는데, 암호화 없이 http로 보낸다는 것”임

• “당연히 사전 프로그램은 웹사이트와 연결된 코드가 있다”란 말에 대해, 실제로는 목적에 따라 다름을 말하고 싶음. 내가 제공하는 Finnish 사전(tsk)의 최소 버전은 약 30MB 용량에 약 25만 단어를 포함해서, 아예 바이너리에 딕셔너리가 박혀있고, 실행 때마다 prefix 검색을 재구성함. 하지만 lemmatization, 어원 등 포함된 거대한 데이터베이스는 수십 기가바이트까지 불어날 수 있음. 나는 완전히 즉각적인 키보드 입력 단위 탐색이 목적이라, 이런 구조가 필요했음. 노력도 많이 들어서, 이후 버전부터는 유료화하기로 결정함 tsk Github 유료 버전 홈페이지 (현재는 Win용 코드서명 문제로 오프라인 중임). 대부분의 다른 사용 사례라면 서버에 질의하는 게 훨씬 편함. 거대한 사전을 전부 다운로드할 이유가 거의 없으니, 혼합형 구조(예: 상위 1만 단어만 로컬에 캐시, 나머지 희귀 단어는 서버와 통신)도 꽤 합리적임

• 이런 걸 보면 악의가 있다고밖에 생각할 수 없는 점이 많음. 관리자는 “사용자가 ‘스캔’ 기능을 직접 활성화했고, 텍스트를 선택하면 번역 동작을 트리거한다... 왜 confidential한 데이터를 번역 질의 대상으로 선택하냐?”라고 답했음

  • 혹시 관리자가 외국어 안에 비밀이 있다는 걸 분간 못 하는 건 아닐지... 예를 들어서 “秘密”라고 써있는 경우에는 말임. “팀장님, 적군이 번역 서버 에러를 겪고 있다고 합니다!”

• Debian에 투입되는 많은 노력은 존경하지만, 패키지 매니저의 이런 “최대주의”가 늘 싫었음. 예를 들어 foo를 설치하려 하면, 가능한 모든 관련 소프트웨어까지 같이 설치하고, 네트워크 데몬까지 있다면 바로 돌려버리는 식임. “추천 패키지” 설치를 막는 플래그가 있다는 건 알지만, 기본 설정이 오히려 사용자에게 불편함을 준다고 느낌

  • 공손하게 반론함. “추천(Recommends)”은 설치한 패키지의 주요 기능을 확장하는 데 쓰임. 이게 없다고 패키지가 망가지진 않지만, 막강한 기능이 비활성화됨. 제기한 패키지는 “추천”이 아니라 “제안(Suggests)”으로 분류되어야 함. “제안”은 기본적으로 설치되지 않음. apt나 aptitude 사용 시, 설치 미리보기가 제공되고 사용자는 그걸 고를 수 있음. 최소주의와 사용자 편의성 사이에 긴장감이 있음. Debian 13 릴리스에선 “Debian은 절대 사용자 친화적 배포판이 아니다”란 의견도 있었음. 개인적으로는 “DIY DIY용 IKEA 스타일”보다 “안정적, 기본에 충실하면서 사용자 친화적인 배포판”이 더 나음. 그리고 고급 사용자는 원하면 언제든 변경 가능함. 기본 변경이 필요하다면 /etc/apt/conf.d/에서 가능, 일회성으론 --no-install-recommends 사용하면 됨
  • 이건 편리함과 보안 사이에서 밸런스를 찾으려는 고전적 딜레마임. Debian의 “추천” 기본값은 네트워크가 상수로 존재하지 않았고, 로컬 기능성이 보안 경계보다 더 중시되던 시대를 전제로 설계된 것임
  • 원래 APT::Install-Recommends 기본값은 false였고, Debian 6.0 Squeeze(2011-02-06)에서 true로 바뀜. 그때는 Debian, Ubuntu에서 불필요한 패키지가 많이 깔려서 싫었음. 지금 생각해보면, 추천과 제안 구분이 애매하기도 했었고, ‘추천’을 기본으로 설치하고, 사용자가 opt-out할 수 있게 한 게 낫다고 생각하게 됨. 그럼에도 내가 직접 관리하는 시스템은 추천 패키지 자동설치를 여전히 끔
  • --install-recommends가 기본인 건 문제없음. Recommends는 “우리 대부분은 이걸 원한다”, Suggests는 “소수 기능”의 미묘한 차이를 두는 게 나쁘지 않음. 그러나 나 역시 개별 유지보수가 Recommends 필드를 남용하는 건 문제라고 생각함. 예를 들어 압축툴 설치하는데 특정 init 시스템까지 강제되는 건 말이 안 됨(file-roller, gnome 관련 팀을 보고 있음)
  • 반대로, 필요한 기능이 opt-in 옵션이라 누락되는 것도 곤란함. 문제는 “추천” 패키지의 설치 여부보다는 패키지 추천 자체가 좀 더 보수적이어야 한다는 점임. 참고로 Debian은 이미 recommended와 suggested로 의무성과 선택성을 나누고 있음

• 왜 이 모든 기능이 오프라인이 아닐까 이해 안 됨. 중국어 사전 전체가 40만 단어 미만이고, 단어당 1k씩만 잡아도 400MB면 충분함. 로컬로 충분히 구현 가능한데, 네트워크 연결에 의존하는 건 단지 설계 미숙임

  • 그럼 먼저 copyleft 사전이 필요할 것임

• 이런 이슈를 보면 엄청나게 화가 남. 이건 절대로 용납될 수 없는 일임

  • 혼자가 아니라고 말해주고 싶음. 빌 게이츠가 파이 던질 때처럼 뭔가 정신 번쩍 들 만한 일이 필요함