StarDict transmite el portapapeles de X11 a servidores remotos

• Se descubrió un grave problema de seguridad en StarDict que envía la selección de texto del usuario en entornos X11 a servidores externos mediante HTTP sin cifrar
• El problema ocurre porque los complementos de YouDao y dict.cn están activados por defecto en la configuración predeterminada de Debian
• Esto significa que cuando el usuario selecciona cualquier texto, se envía automáticamente al servidor, con riesgo de filtración de información sensible
• Los mantenedores del paquete revisaron propuestas para desactivar la función y separar los complementos, pero la aplicación de una solución de fondo ha sido insuficiente
• El problema ya se había señalado varias veces en el pasado, y vuelve a mostrar la falta de una respuesta completa y la importancia de la conciencia de seguridad

---

Resumen del funcionamiento de StarDict y del problema de seguridad

• StarDict es un programa de diccionario multiplataforma con licencia GPLv3, con soporte para varios idiomas y un ecosistema de complementos
• En la configuración predeterminada de Debian, al ejecutar StarDict, el texto seleccionado por el usuario se envía a dos servidores remotos, youdao.com y dict.cn, mediante HTTP sin cifrar
• El problema también fue reportado en la lista de correo oss-security y en el rastreador de errores de Debian

Detalles del problema

• Por diseño de StarDict, el código que se comunica con sitios web de diccionarios puede parecer una configuración natural, pero la función de "escaneo" está activada por defecto
  • Esto significa que cuando el usuario selecciona texto con el mouse, aparece automáticamente una ventana emergente de traducción y ese texto se envía automáticamente a servidores externos
  • El problema se vuelve grave cuando el usuario mantiene StarDict ejecutándose siempre en segundo plano

Diferencias según el entorno Linux

• En Wayland, StarDict no puede capturar texto de otras aplicaciones, por lo que la función de escaneo no funciona y no se produce este problema de seguridad
• El problema existe actualmente solo en el entorno X11 tradicional

Respuesta de Debian y de los desarrolladores de StarDict

• El mantenedor del paquete de Debian, Xiao Sheng Wen, no lo consideró un problema grave y señaló que "la función de escaneo y el complemento de YouDao pueden desactivarse"
• Sin embargo, el reportante Vincent Lefevre indicó que "las funciones relacionadas con la privacidad deben estar desactivadas por defecto"
• Es posible informar esta función a través de la descripción del paquete, pero la descripción de stardict-plugin no menciona el uso de diccionarios en línea
• Se han propuesto mejoras como la separación de complementos, pero no se tomaron medidas inmediatas

Comodidad de la función y preocupaciones de seguridad

• La función de escaneo es una ventaja principal de StarDict cuando se quiere consultar rápidamente un diccionario al leer en un idioma extranjero
• Sin embargo, es difícil que el usuario espere que esa comunicación no esté cifrada. Cualquiera en la ruta intermedia puede exponer texto sensible

Incidentes de seguridad similares en el pasado y respuesta

• En 2009 y 2015 también se reportaron casos similares
  • 2009: desactivar los diccionarios de red se aplicó temporalmente como valor predeterminado
  • Sin embargo, el complemento YouDao agregado en 2016 ignoró esa configuración
  • El problema de 2015 recién se resolvió en 2025 mediante la eliminación del complemento
• De este modo, se han repetido la reaparición del problema y la demora en la respuesta, junto con cambios de mantenedores y fallas de priorización

Escala de usuarios e impacto de seguridad

• Según las estadísticas de Debian, actualmente solo unas 178 personas tienen StarDict instalado, pero considerando sistemas que no participan en esas estadísticas, muchos usuarios podrían haber estado expuestos durante años al riesgo de filtración de texto
• Copiar contraseñas, correos sensibles o texto seleccionado mientras se edita un documento, entre otros casos, podría quedar expuesto externamente tal cual

El ecosistema open source y la agenda de seguridad

• Una gran distribución como Debian administra muchísimos paquetes, y son frecuentes las omisiones de actualizaciones y el envejecimiento del software
• Incluso la ley de Linus, según la cual "con suficientes ojos, todos los bugs son superficiales", solo se cumple si alguien descubre el error, lo reporta y luego un mantenedor lo reconoce como problema y lo corrige

El cambio de X11 a Wayland

• La adopción de Wayland busca reducir este tipo de fallas de seguridad, especialmente la posibilidad de filtración de información entre aplicaciones
• Aun así, siguen siendo un reto las incomodidades funcionales y las nuevas formas de gestionar permisos de uso

Conclusión e implicaciones

• Preocupa la realidad de que problemas de seguridad que se descubren, diagnostican y reportan sigan sin resolverse o vuelvan a aparecer
• Para mantener la reputación de seguridad de Linux, es indispensable que desarrolladores de open source, responsables del mantenimiento de paquetes y usuarios mantengan una conciencia constante del problema y respondan con rapidez

[GN⁺]

Opiniones de Hacker News

• Como señaló Xiao, quienes instalan software pueden leer la descripción del paquete, y de hecho sí se menciona la función de escaneo. Pero los mantenedores de Debian a menudo responden a reportes de errores con algo como “hay que leer con cuidado todas las descripciones de los paquetes (incluso los cientos que se instalan como dependencias)”, y sinceramente, si hubieras empezado a leer todas las descripciones y README con la distribución Trixie de hace unos días, probablemente todavía no terminarías

  • “Los planos y la orden de demolición estuvieron exhibidos en la oficina local de Alpha Centauri durante cincuenta años de su tiempo terrestre. Si no te interesa enterarte de los asuntos locales...” da justo esa sensación enlace al video de YouTube
  • Cuando dan ese tipo de respuesta, no puedo verlo de otra forma que como mala fe
  • Cuando instalo un programa desde los repositorios de Debian, es por conveniencia y confianza. Ya molesta bastante cuando los mantenedores cambian el comportamiento del paquete, pero habría sido mucho mejor que una función que envía información del portapapeles a terceros fuera opt-in, es decir, que hubiera que activarla de forma explícita. Es una traición a la confianza
  • Estoy de acuerdo en que, con la salida de Trixie, es difícil leer todas las descripciones de paquetes y los README. Cuando empecé a usar Debian a fines de los 90 y principios de los 2000, podías elegir los paquetes que querías con dselect y, si le dedicabas unas horas, ajustar todas las opciones a tu entorno de hardware real (en ese tiempo no era tan dinámico como ahora, así que había que seleccionar todo una por una). Hoy hay demasiados paquetes y la configuración del kernel se volvió excesivamente grande, así que ya no es realista revisar todo (¿todavía hay gente que usa dselect...?)
  • Estoy de acuerdo con lo que dijiste. Sobre todo porque ese mantenedor ya ha introducido comportamientos inesperados varias veces; como en un problema anterior, ha seguido repitiendo conductas inapropiadas como modificar incluso archivos de configuración de otros paquetes. Esto debería sacarse del repositorio

• Claro, uno podría pensar que un programa de diccionario incluye código para comunicarse con sitios web. Pero si instalo un diccionario con apt-get, espero tener el diccionario completo en mi computadora. Después de todo, los diccionarios en papel existen desde hace siglos... StarDict es más bien en línea, y podrá ser normal, pero da una sensación de trampa

  • Creo que esto es una diferencia generacional. La gente joven, que ve como normal que una app se comunique con internet, no está acostumbrada al software instalado localmente que no habla con el exterior. Incluso buscando el historial del desarrollador, se nota que sabe bastante de informática y entiende perfectamente que un diccionario offline es posible, pero parece seguir lo que su generación considera “normal”. Es triste que, en el mundo actual, las apps que se instalan localmente y funcionan solo con datos offline sean casi una caballería mantenida por unos pocos Quijotes de TI
  • Incluso si fuera normal, usar HTTP sin cifrado es absolutamente inaceptable
  • El viejo programa ding soporta muy bien diccionarios locales. También está en Debian enlace a ding
  • A mí también me llamó la atención ese punto. Es triste vivir en un mundo donde incluso una función tan simple se espera como servicio en línea
  • Desde cierto momento empecé a ejecutar las apps con interfaz gráfica sin acceso a red. Primero con firejail, luego con bubblewrap, y con el tiempo con scripts en bash que hice para correr apps en entornos aislados. Llevo haciéndolo desde antes de flatpak

• Me sorprendió bastante enterarme de que, en los teléfonos Samsung, todos los datos del portapapeles se comparten entre todos los dispositivos de mi cuenta Samsung (incluyendo contraseñas) e incluso se guarda el historial. No recuerdo si era la configuración predeterminada o si acepté por accidente. Supongo que esos datos pasan por servidores de Samsung. Desactivé la función de compartir, pero el historial del portapapeles no se desactiva, y aunque cambie de teclado, si vuelvo al teclado de Samsung, sigue apareciendo todo el historial anterior. Mi próximo teléfono no va a ser Samsung

  • Según entiendo, lo mismo pasa con las TVs de Samsung: comparten historial de uso y datos personales con empresas de marketing. La política de privacidad de Samsung es la misma para teléfonos y TVs
  • Vi que contraseñas copiadas en Linux a través de KDE Connect terminaban en el historial del portapapeles de Android. Me pregunto si habrá forma de evitar que se copien solo las contraseñas, sin tener que desactivar por completo el uso compartido del portapapeles
  • Cuando uses dispositivos Samsung, recomiendo no crear ni iniciar sesión en una cuenta Samsung. Eso reduce muchísimo las oportunidades que tiene la empresa de acceder a tus datos

• Siento que la discusión sobre Wayland se presta un poco a confusión. El resumen final es correcto: “Tal vez StarDict habría pedido permisos especiales para funcionar en Wayland, y el usuario los habría aceptado por defecto, igual que ahora.” O sea, es muy probable, y quizá esos permisos incluso se habrían configurado automáticamente durante la instalación. El malware siempre existe. Wayland puede defenderte de ciertos ataques, pero no te protege de paquetes instalados como parte de la distribución

  • No es una confusión: Wayland sí es claramente mejor que Xorg en ese aspecto. Pero el problema de fondo es más estructural que eso. Por ejemplo, ¡los datos que se enviaban ni siquiera iban cifrados! En X11, con la configuración predeterminada de Debian, StarDict enviaba por HTTP a dos servidores remotos el texto que el usuario seleccionaba. Aunque uno hubiera leído con atención la descripción del paquete o el plugin de YouDao, al menos esperaría que la comunicación estuviera cifrada. Pero en realidad enviaba los datos por HTTP sin ninguna seguridad a los servidores dict.youdao.com y dict.cn, así que cualquiera en esa ruta podía ver el contenido de las solicitudes

• Consultar un diccionario local a partir del portapapeles está bien. Añadir una función para consultar un diccionario remoto también está bien. Incluso combinar ambas cosas de manera sencilla sería razonable si estuvieran separadas mediante algún flag especial. Pero mezclar esas dos funciones en la configuración predeterminada es casi un acto malicioso

  • El youdao del que hablan aquí es un servicio de traducción. La traducción offline está muy por debajo de la traducción en línea; o sea, yo solo querría usar algo como un paquete local de traducción offline de Google cuando no tengo datos. No uso Stardict, pero si quieres algo más que solo definiciones de palabras, ese comportamiento es bastante esperable. En resumen, el punto central de todo este artículo es: “un programa chino de traducción enviaba datos del portapapeles a su sitio web y a un servicio chino de traducción, y además lo hacía por http sin cifrado”

• Sobre la frase “por supuesto un programa de diccionario tiene código conectado a sitios web”, diría que en realidad depende del propósito. La versión mínima del diccionario finlandés que ofrezco (tsk) pesa unos 30MB e incluye alrededor de 250 mil palabras, con el diccionario incrustado directamente en el binario y reconstruyendo la búsqueda por prefijo en cada ejecución. Pero una base de datos enorme con lematización, etimología, etc., puede crecer hasta decenas de gigabytes. Mi objetivo era una exploración completamente inmediata al ritmo de la escritura en teclado, así que necesitaba esa estructura. También requirió mucho esfuerzo, así que decidí cobrar a partir de versiones posteriores tsk Github sitio de la versión de pago (por ahora está fuera de línea por problemas de firma de código en Windows). Para la mayoría de los demás casos de uso, consultar un servidor es mucho más cómodo. Casi nunca hay motivo para descargar un diccionario gigantesco completo, así que una estructura híbrida (por ejemplo, cachear localmente las 10 mil palabras más comunes y consultar al servidor para las raras) también suena bastante razonable

• Viendo esto, hay demasiadas cosas que solo me hacen pensar en mala intención. El mantenedor respondió: “el usuario activó manualmente la función de ‘escaneo’, y seleccionar texto dispara la traducción... ¿por qué seleccionaría datos confidenciales para una consulta de traducción?”

  • Capaz el mantenedor no puede distinguir si hay secretos en un idioma extranjero... por ejemplo, cuando dice “秘密”. “¡Jefe, parece que el enemigo está teniendo errores con el servidor de traducción!”

• Respeto mucho el trabajo que se invierte en Debian, pero siempre me ha molestado este “maximalismo” del gestor de paquetes. Por ejemplo, intentas instalar foo y termina instalando también todo el software relacionado posible, e incluso arrancando demonios de red si los hay. Sé que existe un flag para evitar instalar “paquetes recomendados”, pero siento que la configuración predeterminada termina perjudicando al usuario

  • Con respeto, discrepo. “Recommends” se usa para ampliar la funcionalidad principal del paquete instalado. El paquete no queda roto sin eso, pero sí se desactivan funciones potentes. El paquete mencionado debería clasificarse como “Suggests”, no como “Recommends”. “Suggests” no se instala por defecto. Cuando usas apt o aptitude, se muestra una vista previa de la instalación y el usuario puede decidir. Hay una tensión entre el minimalismo y la comodidad del usuario. En el lanzamiento de Debian 13 también hubo quien decía que “Debian jamás es una distribución amigable para el usuario”. Personalmente prefiero una distribución “estable, sensata y amigable” antes que una “tipo IKEA para DIY del DIY”. Y los usuarios avanzados siempre pueden cambiarlo si quieren. Si necesitas cambiar el valor por defecto, puedes hacerlo en /etc/apt/conf.d/, y para algo puntual puedes usar --no-install-recommends
  • Este es el dilema clásico de buscar equilibrio entre comodidad y seguridad. El valor predeterminado de “Recommends” en Debian fue diseñado en una época en la que la red no era una constante y la funcionalidad local se valoraba más que el perímetro de seguridad
  • Originalmente, el valor predeterminado de APT::Install-Recommends era false, y se cambió a true en Debian 6.0 Squeeze (2011-02-06). En ese momento no me gustaba que se instalaran tantos paquetes innecesarios en Debian y Ubuntu. Viéndolo ahora, también es cierto que la distinción entre recommends y suggests a veces era ambigua, y terminé pensando que era mejor instalar “recommends” por defecto y dejar que el usuario pudiera excluirlos. Aun así, en los sistemas que administro yo sigo desactivando la instalación automática de paquetes recomendados
  • No tengo problema con que --install-recommends sea el valor por defecto. No está mal esa diferencia sutil de Recommends como “la mayoría de nosotros quiere esto” y Suggests como “función para minorías”. Pero también creo que es un problema cuando mantenedores individuales abusan del campo Recommends. Por ejemplo, no tiene sentido que al instalar una herramienta de compresión también te fuerce cierto sistema init (estoy viendo a file-roller y al equipo de gnome)
  • A la inversa, también sería problemático que una función necesaria quedara como opción opt-in y se omitiera. El problema no es tanto si se instalan o no los paquetes “recomendados”, sino que las recomendaciones en sí deberían ser más conservadoras. Como referencia, Debian ya separa la obligatoriedad y opcionalidad entre recommended y suggested

• No entiendo por qué todo esto no es offline. Un diccionario chino completo tiene menos de 400 mil palabras y, aun calculando 1k por palabra, con 400MB alcanzaría. Esto se puede implementar localmente sin problema; depender de una conexión de red es simplemente mal diseño

  • Entonces primero haría falta un diccionario con copyleft

• Ver este tipo de cosas me da una rabia enorme. Esto es absolutamente inaceptable

  • Quiero decirte que no eres el único. Hace falta algo que despabile a la gente, como cuando le aventaron un pastel a Bill Gates