StarDict gửi clipboard X11 tới máy chủ từ xa

• Đã phát hiện một lỗ hổng bảo mật nghiêm trọng khi StarDict trong môi trường X11 gửi phần văn bản người dùng chọn tới máy chủ bên ngoài qua HTTP không mã hóa
• Sự cố này xảy ra vì các plugin YouDao và dict.cn được bật mặc định trong cấu hình mặc định của Debian
• Điều này có nghĩa là mỗi khi người dùng chọn bất kỳ đoạn văn bản nào, nó sẽ tự động được gửi lên máy chủ, kéo theo nguy cơ rò rỉ thông tin nhạy cảm
• Người quản lý gói đã xem xét đề xuất vô hiệu hóa tính năng và tách plugin, nhưng việc áp dụng giải pháp tận gốc vẫn còn thiếu sót
• Vấn đề này đã nhiều lần được nêu ra trong quá khứ, một lần nữa cho thấy sự thiếu vắng phản ứng triệt để và tầm quan trọng của nhận thức bảo mật

---

Tổng quan về cách StarDict hoạt động và vấn đề bảo mật

• StarDict là một chương trình từ điển đa nền tảng theo giấy phép GPLv3, hỗ trợ nhiều ngôn ngữ và có hệ sinh thái plugin phong phú
• Trong cấu hình mặc định của Debian, khi chạy StarDict, văn bản do người dùng chọn sẽ được gửi tới hai máy chủ từ xa youdao.com và dict.cn qua HTTP không mã hóa
• Vấn đề này cũng đã được báo cáo trên danh sách thư oss-security và trình theo dõi lỗi của Debian

Chi tiết vấn đề

• Về mặt thiết kế của StarDict, phần mã giao tiếp với các website từ điển là một cấu phần tự nhiên, nhưng tính năng "quét" lại được bật mặc định
  • Điều này có nghĩa là khi người dùng chọn văn bản bằng chuột, một cửa sổ bật lên dịch thuật sẽ tự động xuất hiện, đồng thời văn bản đó cũng tự động bị gửi tới máy chủ bên ngoài
  • Vấn đề đặc biệt nghiêm trọng khi người dùng luôn để StarDict chạy nền

Khác biệt giữa các môi trường Linux

• Trong môi trường Wayland, StarDict không thể chụp văn bản từ ứng dụng khác, nên tính năng quét không hoạt động và không phát sinh vấn đề bảo mật này
• Vấn đề này hiện chỉ tồn tại trong môi trường X11 truyền thống

Phản ứng từ Debian và các nhà phát triển StarDict

• Người quản lý gói Debian Xiao Sheng Wen cho rằng đây không phải vấn đề lớn vì "có thể vô hiệu hóa tính năng quét và plugin YouDao"
• Tuy nhiên, người báo cáo Vincent Lefevre chỉ ra rằng "các tính năng liên quan tới quyền riêng tư bắt buộc phải bị tắt theo mặc định"
• Có thể thông báo tính năng này qua phần mô tả gói, nhưng mô tả của stardict-plugin không hề đề cập tới việc sử dụng từ điển trực tuyến
• Đã có đề xuất cải thiện như tách plugin riêng, nhưng chưa có hành động tức thời

Sự tiện lợi của tính năng và lo ngại bảo mật

• Tính năng quét là một ưu điểm lớn của StarDict khi người dùng muốn tra từ điển nhanh lúc đọc ngoại ngữ
• Nhưng người dùng khó có thể ngờ rằng giao tiếp này không được mã hóa. Bất kỳ ai trên đường truyền trung gian đều có thể thấy văn bản nhạy cảm

Các sự cố bảo mật tương tự trước đây và cách xử lý

• Những trường hợp tương tự cũng từng được báo cáo vào năm 2009 và 2015
  • Năm 2009: việc vô hiệu hóa từ điển mạng từng được áp dụng tạm thời làm mặc định
  • Tuy nhiên plugin YouDao được thêm vào năm 2016 lại bỏ qua thiết lập đó
  • Vấn đề năm 2015 mãi tới năm 2025 mới được xử lý theo hướng loại bỏ plugin
• Có thể thấy vấn đề tái diễn và phản ứng chậm chạp, cùng việc thay đổi người bảo trì và ưu tiên xử lý chưa phù hợp, đã lặp lại nhiều lần

Quy mô người dùng và tác động bảo mật

• Theo thống kê của Debian, hiện chỉ có khoảng 178 người cài và dùng StarDict, nhưng nếu tính cả các hệ thống không tham gia thống kê thì trong nhiều năm qua có thể đã có khá nhiều người dùng bị phơi bày trước nguy cơ rò rỉ văn bản
• Mật khẩu được sao chép, email nhạy cảm, đoạn văn bản được chọn khi đang chỉnh sửa tài liệu đều có thể bị lộ nguyên trạng ra bên ngoài

Hệ sinh thái mã nguồn mở và nghị trình bảo mật

• Những bản phân phối lớn như Debian phải quản lý rất nhiều gói, nên tình trạng bỏ sót cập nhật và phần mềm lỗi thời xảy ra thường xuyên
• Định luật Linus rằng "nếu đủ nhiều người cùng nhìn thì lỗi sẽ trở nên nông" chỉ đúng khi thực sự có ai đó phát hiện lỗi, báo cáo nó, và người bảo trì công nhận rồi sửa chữa

Sự chuyển dịch từ X11 sang Wayland

• Việc đưa Wayland vào sử dụng nhằm giảm chính kiểu lỗ hổng bảo mật này, đặc biệt là khả năng rò rỉ thông tin giữa các ứng dụng
• Tuy vậy, sự bất tiện về mặt chức năng và cách xử lý quyền truy cập mới đi kèm vẫn là những thách thức còn lại

Kết luận và hàm ý

• Thực tế rằng những vấn đề bảo mật được phát hiện, chẩn đoán và báo cáo vẫn có thể chưa được xử lý hoặc tiếp tục tái diễn là điều đáng lo ngại
• Để duy trì uy tín bảo mật của Linux, cần có sự nhận thức liên tục và phản ứng nhanh từ các nhà phát triển mã nguồn mở, người phụ trách quản lý gói và người dùng

[GN⁺]

Ý kiến Hacker News

• Như Xiao đã chỉ ra, người cài phần mềm có thể đọc mô tả gói, và thực tế tính năng quét đã được nhắc tới. Nhưng các quản trị viên Debian thường trả lời báo cáo lỗi theo kiểu “bạn phải đọc kỹ mô tả của mọi gói (kể cả hàng trăm gói được cài như phụ thuộc)”, mà thành thật thì nếu vài ngày trước bạn bắt đầu đọc hết mọi mô tả và README của bản phát hành Trixie, có lẽ đến giờ vẫn chưa đọc xong

  • “Các kế hoạch và lệnh cưỡng chế phá dỡ đã được trưng bày tại văn phòng địa phương ở Alpha Centauri suốt năm mươi năm theo thời gian Trái Đất của các anh. Nếu các anh không quan tâm tới chuyện địa phương thì…” cảm giác rất đúng với đoạn này liên kết video YouTube
  • Với kiểu trả lời như vậy, tôi chỉ có thể xem đó là có ác ý
  • Khi tôi cài chương trình từ kho Debian, đó là vì sự tiện lợi và niềm tin. Dù tôi đã nhiều lần không hài lòng khi bên bảo trì thay đổi hành vi của gói, sẽ tốt hơn nhiều nếu tính năng gửi dữ liệu clipboard cho người khác là opt-in, tức chỉ hoạt động khi được bật rõ ràng. Đây là hành động phản bội niềm tin
  • Tôi đồng ý rằng ở bản phát hành Trixie, việc đọc hết mọi mô tả gói và README là quá khó. Hồi cuối thập niên 90 đến đầu 2000, khi tôi mới dùng Debian, chỉ cần chọn các gói mình muốn bằng dselect rồi bỏ ra vài tiếng là có thể chỉnh mọi tùy chọn cho phù hợp với phần cứng thực tế (khi đó hệ thống chưa động như bây giờ nên phải chọn từng mục một). Còn bây giờ số lượng gói quá nhiều, cấu hình kernel cũng đã phình ra quá mức, nên không còn là thế giới mà bạn có thể kiểm tra hết mọi thứ một cách thực tế nữa (còn ai dùng dselect không... có chứ?)
  • Tôi đồng ý với bạn. Đặc biệt vì người bảo trì gói đó đã nhiều lần tạo ra hành vi ngoài dự kiến, như vấn đề cũ này, thậm chí còn sửa cả file cấu hình của gói khác; kiểu hành xử không phù hợp này cứ lặp đi lặp lại. Loại này nên bị gỡ khỏi kho

• Dĩ nhiên, với một chương trình từ điển thì người ta có thể cho rằng nó sẽ chứa mã giao tiếp với website. Nhưng nếu tôi cài một từ điển bằng apt-get, tôi có thể kỳ vọng là toàn bộ từ điển nằm trên máy của mình. Xét cho cùng, từ điển giấy đã được dùng hàng trăm năm rồi mà... Stardict thì thiên về trực tuyến, có thể là bình thường, nhưng vẫn cho cảm giác như có cái bẫy nào đó

  • Tôi nghĩ đây là khác biệt thế hệ. Những người xem việc ứng dụng giao tiếp với Internet là hiển nhiên thường là thế hệ trẻ, không quen với phần mềm cài cục bộ mà không liên lạc ra ngoài. Tra hồ sơ của lập trình viên đó thì thấy rõ là người rất giỏi khoa học máy tính và cũng thừa biết từ điển ngoại tuyến là khả thi, nhưng có vẻ anh ta chỉ đang đi theo cái “hiển nhiên” của thế hệ mình. Thật buồn khi trong thế giới hiện tại, ứng dụng cài cục bộ rồi chỉ chạy bằng dữ liệu ngoại tuyến giống như tinh thần hiệp sĩ vậy, chỉ còn được duy trì bởi một số ít Don Quixote IT
  • Dù có là bình thường đi nữa, việc dùng HTTP không mã hóa là hoàn toàn không thể chấp nhận được
  • Chương trình ding cũ hỗ trợ từ điển cục bộ rất tốt. Nó cũng có trong Debian liên kết ding
  • Tôi cũng chú ý tới điểm này. Thật buồn khi đến cả chức năng đơn giản như vậy mà người ta cũng mặc định phải là một dịch vụ trực tuyến
  • Từ một thời điểm nào đó, tôi bắt đầu chạy ứng dụng GUI mà không cho quyền truy cập mạng. Ban đầu là firejail, sau đó là bubblewrap, rồi theo thời gian là các script bash tôi tự viết để chạy ứng dụng trong môi trường sandbox. Tôi đã làm vậy từ trước cả thời flatpak

• Tôi đã khá sốc khi phát hiện trên điện thoại Samsung, toàn bộ dữ liệu clipboard được chia sẻ giữa mọi thiết bị trong tài khoản Samsung của tôi (kể cả mật khẩu), và thậm chí còn lưu cả lịch sử. Tôi không nhớ đó có phải mặc định hay do mình vô tình đồng ý. Tôi đoán dữ liệu này được chuyển qua máy chủ của Samsung. Tôi đã tắt tính năng chia sẻ, nhưng lịch sử clipboard thì không tắt được; dù đổi sang bàn phím khác, chỉ cần chuyển lại về bàn phím Samsung là toàn bộ lịch sử clipboard cũ vẫn còn đó. Giờ tôi nghĩ điện thoại tiếp theo sẽ không chọn Samsung nữa

  • TV Samsung cũng vậy, theo tôi biết thì chúng chia sẻ lịch sử xem và dữ liệu cá nhân với các công ty marketing. Chính sách quyền riêng tư của Samsung cho điện thoại và TV là như nhau
  • Tôi từng thấy mật khẩu được copy từ Linux qua KDE connect vẫn hiện trong lịch sử clipboard của Android. Tôi tự hỏi có cách nào chặn không cho chỉ riêng mật khẩu bị chuyển đi, mà không cần tắt hoàn toàn việc chia sẻ clipboard
  • Khi dùng thiết bị Samsung, tôi khuyên là đừng tạo hay đăng nhập tài khoản Samsung. Việc đó sẽ giảm mạnh cơ hội công ty truy cập dữ liệu của bạn

• Tôi cảm thấy có chút gây hiểu lầm trong phần nói về Wayland. Phần tóm tắt cuối là chính xác: “Có lẽ StarDict đã yêu cầu quyền đặc biệt để chạy trên Wayland, và người dùng đã chấp nhận giá trị mặc định đó như bây giờ.” Tức là khả năng lớn là vậy, và quyền đó cũng có thể đã được gán tự động trong quá trình cài đặt. Phần mềm độc hại thì lúc nào cũng tồn tại. Wayland có thể ngăn được một số kiểu tấn công, nhưng nó không bảo vệ bạn khỏi các gói được cài như một phần của bản phân phối

  • Không phải hiểu lầm đâu, Wayland đúng là tốt hơn Xorg ở khía cạnh này. Nhưng bản chất vấn đề còn mang tính cấu trúc hơn thế. Ví dụ dữ liệu được gửi đi thậm chí còn không được mã hóa! Trên X11, với cấu hình Debian mặc định, StarDict sẽ gửi đoạn văn bản do người dùng chọn qua HTTP tới hai máy chủ từ xa. Dù bạn có đọc kỹ mô tả gói hay plugin YouDao đi nữa, ít nhất bạn cũng sẽ kỳ vọng việc liên lạc được mã hóa. Nhưng thực tế dữ liệu lại được gửi đến các máy chủ dict.youdao.com và dict.cn qua HTTP hoàn toàn không an toàn, nên bất kỳ ai trên đường truyền cũng có thể nhìn thấy nội dung yêu cầu

• Việc tra từ điển cục bộ cho mỗi clipboard là ổn. Thêm tính năng truy vấn từ điển từ xa cũng không sao. Ngay cả việc kết hợp hai tính năng này cũng có thể chấp nhận nếu được tách riêng bằng một cờ đặc biệt nào đó, nhưng trộn chúng lại trong thiết lập mặc định thì gần như là hành vi ác ý

  • youdao ở đây là một dịch vụ dịch thuật. Dịch ngoại tuyến kém xa dịch trực tuyến, nghĩa là tôi chỉ muốn dùng thứ như gói local google offline translation khi không có dữ liệu mà thôi. Tôi không dùng Stardict, nhưng nếu bạn muốn làm nhiều hơn là chỉ tra nghĩa từ đơn lẻ thì hành vi như vậy là hoàn toàn có thể dự đoán được. Nói ngắn gọn, ý chính của cả bài này là “một chương trình dịch tiếng Trung đã gửi dữ liệu clipboard đến website của nó và một dịch vụ dịch thuật của Trung Quốc, và còn gửi bằng HTTP không mã hóa”

• Về câu “đương nhiên chương trình từ điển có mã kết nối website”, tôi muốn nói rằng thực tế còn tùy vào mục đích sử dụng. Phiên bản tối giản của từ điển tiếng Phần Lan (tsk) mà tôi làm có dung lượng khoảng 30MB với khoảng 250 nghìn từ, và toàn bộ từ điển được nhúng thẳng vào binary; mỗi lần chạy nó sẽ dựng lại phần tìm kiếm theo tiền tố. Nhưng cơ sở dữ liệu khổng lồ có thêm lemmatization, từ nguyên học v.v. có thể phình lên tới hàng chục gigabyte. Tôi cần cấu trúc này vì mục tiêu là tra cứu hoàn toàn tức thời theo từng nhịp gõ bàn phím. Tôi đã bỏ rất nhiều công sức, nên từ các phiên bản sau tôi quyết định thu phí tsk Github trang chủ bản trả phí (hiện đang offline vì vấn đề code signing cho Win). Với hầu hết trường hợp sử dụng khác, truy vấn lên máy chủ sẽ tiện hơn rất nhiều. Hầu như không có lý do gì để tải xuống toàn bộ một từ điển khổng lồ, nên cấu trúc lai (ví dụ cache cục bộ 10 nghìn từ phổ biến nhất, còn từ hiếm thì hỏi máy chủ) cũng khá hợp lý

• Càng nhìn càng thấy nhiều điểm chỉ có thể hiểu là có ác ý. Người bảo trì trả lời rằng “người dùng đã tự bật tính năng ‘quét’, và việc chọn văn bản sẽ kích hoạt dịch... vậy tại sao lại chọn dữ liệu confidential để dịch?”

  • Hay là người bảo trì không phân biệt nổi trong ngoại ngữ đâu là bí mật... ví dụ khi nó ghi “秘密” chẳng hạn. “Sếp ơi, quân địch đang gặp lỗi với máy chủ dịch!”

• Tôi rất tôn trọng lượng công sức đổ vào Debian, nhưng lúc nào cũng ghét kiểu “tối đa hóa” này của trình quản lý gói. Ví dụ cài foo thì nó kéo theo mọi phần mềm liên quan có thể có, và nếu có daemon mạng thì còn cho chạy luôn. Tôi biết có cờ để chặn cài “gói khuyến nghị”, nhưng tôi vẫn thấy mặc định như vậy là làm người dùng khổ hơn

  • Xin phép phản biện một cách lịch sự. “Recommends” được dùng để mở rộng chức năng chính của gói đã cài. Không có nó thì gói không hỏng, nhưng những tính năng mạnh mẽ sẽ bị vô hiệu hóa. Gói đang được nói tới nên được xếp là “Suggests” chứ không phải “Recommends”. “Suggests” mặc định không được cài. Khi dùng apt hay aptitude, bạn có phần xem trước cài đặt và người dùng có thể chọn ở đó. Ở đây luôn có căng thẳng giữa chủ nghĩa tối giản và sự tiện lợi cho người dùng. Trong đợt phát hành Debian 13 cũng có ý kiến rằng “Debian vốn không phải bản phân phối thân thiện với người dùng”. Cá nhân tôi vẫn thích “một bản phân phối ổn định, bám sát giá trị cốt lõi nhưng thân thiện với người dùng” hơn là kiểu “IKEA tự lắp cho người thích DIY”. Và người dùng nâng cao thì lúc nào cũng có thể thay đổi nếu muốn. Nếu cần đổi mặc định thì có thể làm ở /etc/apt/conf.d/, còn dùng một lần thì --no-install-recommends
  • Đây là tình thế tiến thoái lưỡng nan cổ điển giữa tiện lợi và bảo mật. Mặc định “Recommends” của Debian được thiết kế trong thời kỳ mạng chưa phải hằng số hiện diện mọi nơi, và chức năng cục bộ được ưu tiên hơn ranh giới bảo mật
  • Ban đầu mặc định của APT::Install-Recommends là false, rồi được đổi thành true trong Debian 6.0 Squeeze (2011-02-06). Hồi đó tôi ghét việc Debian và Ubuntu cài quá nhiều gói thừa. Giờ nghĩ lại thì ranh giới giữa recommends và suggests đúng là cũng mơ hồ, và có lẽ cài “recommends” theo mặc định rồi để người dùng opt-out lại là phương án tốt hơn. Dù vậy, trên các hệ thống tôi tự quản lý, tôi vẫn tắt tự động cài gói khuyến nghị
  • Việc --install-recommends là mặc định thì không vấn đề gì. Việc tạo ra khác biệt tinh tế giữa Recommends là “đa số chúng ta đều muốn cái này” và Suggests là “tính năng thiểu số” không phải ý tồi. Nhưng tôi cũng đồng ý rằng việc từng người bảo trì riêng lẻ lạm dụng trường Recommends là một vấn đề. Ví dụ cài công cụ nén mà lại kéo theo cả một hệ thống init cụ thể thì thật vô lý (đang nhìn về phía file-roller và nhóm liên quan tới gnome)
  • Ngược lại, việc để tính năng cần thiết thành tùy chọn opt-in rồi bị bỏ sót cũng rất phiền. Vấn đề không hẳn nằm ở chuyện có cài gói “khuyến nghị” hay không, mà là bản thân các khuyến nghị gói nên bảo thủ hơn. Nhân tiện thì Debian đã có sẵn phân biệt giữa recommended và suggested để tách mức độ cần thiết và tùy chọn rồi

• Tôi không hiểu vì sao tất cả việc này lại không làm ngoại tuyến. Toàn bộ từ điển tiếng Trung còn chưa tới 400 nghìn từ, giả sử mỗi từ 1k thì 400MB là đủ. Hoàn toàn có thể làm cục bộ, việc phụ thuộc vào kết nối mạng đơn thuần là thiết kế kém

  • Vậy trước hết bạn sẽ cần một bộ từ điển copyleft

• Cứ thấy những chuyện như thế này là tôi cực kỳ tức giận. Đây là điều tuyệt đối không thể chấp nhận được

  • Tôi chỉ muốn nói là bạn không hề cô đơn. Cần một cú làm người ta tỉnh ra kiểu như lúc Bill Gates bị ném bánh kem vậy