¿Los programas en Ubuntu Software Center son libres de spyware?


35

En el Centro de software de Ubuntu hay diferentes secciones para programas

  • Proporcionado por Ubuntu
  • Socios canónicos
  • Para comprar

Sé que todos estos son de código abierto; pero, ¿hay algún proceso de validación realizado por Canonical para garantizar que estén libres de spyware o malware ?

¡Me pregunto si alguien tendrá tiempo de ver todos estos (2355 programas más o menos a partir de ahora), código de software que también para cada versión !!

Estoy preocupado porque instalo rutinariamente software bastante impopular desde el centro de software :)


1
El software "For Purchase" no es de código abierto, de lo contrario la gente no necesitaría comprarlo. Y el software de socios no siempre es de código abierto, Skype no está abierto, por ejemplo
Martin Ueding

8
@queueoverflow es posible cobrar por software de código abierto.
dv3500ea

3
@queueoverflow: qtiplot sería un ejemplo, cargos por binarios y contratos de soporte, puedes compilarte gratis. :-)
Christoph

2
Bueno, no creo que haya actualmente ningún software de código abierto en la sección For Purchase, pero puede haberlo en el futuro.
dv3500ea

1
@ Christoph: supongo que la mayoría de la gente no sabe cómo compilarlo, por lo que tiene sentido manejarlo así.
Martin Ueding

Respuestas:


27

¿Existe un proceso para garantizar que no haya malware? No. No hay garantías en absoluto.

Sin embargo, existen varios mecanismos para intentar detectarlo, pero si bien no quiero ser demasiado pesimista, si somos honestos, probablemente no estés tan seguro como te gustaría estar.

  1. Primero se debe agregar un proyecto a Ubuntu. Como dice Rinzwind, los controles se realizan en esta etapa, pero esa es realmente solo la punta del iceberg que es la vida de un paquete en Ubuntu.

  2. La primera línea de defensa real para los paquetes a largo plazo son sus mantenedores de proyectos. Estas personas cuidan sus proyectos y aceptan parches para mejorarlos. Son humanos Cometen errores y extrañan cosas. Y algunos pueden ser flojos.

    Es posible que una persona mala pueda pasar un poco de malware al incluir mejoras genuinas junto con el malware.

    Si su mantenedor admite algo malo en un proyecto, guarde una auditoría exitosa, lo más probable es que el código termine en las máquinas de los usuarios de Ubuntu.

  3. Las auditorías de seguridad son el segundo paso. Esto es examinar el código y ejecutarlo contra monitores para detectar cosas malas. Hasta donde sé, no hay un equipo oficial de Canonical dedicado a la seguridad, pero hay dos equipos comunitarios (Ubuntu Security y MOTU SWAT) que manejan todos los paquetes entre ellos.

    La auditoría solo funciona realmente si cada línea de código se verifica correctamente antes de enviarla a los usuarios. Esto no es realmente práctico para la cantidad de código y la cantidad de actualizaciones de las que estamos hablando. Tomaría una gran cantidad de tiempo y dinero hacerlo de esta manera.

    Hay una suposición en el mundo del código abierto de que solo porque alguien puede ver la fuente, lo han hecho. Este es un ethos muy peligroso de mantener.

    Las soluciones de seguridad son en gran medida reaccionarias ante las personas que encuentran y revelan agujeros. ¿Qué sucede si alguien revela un agujero que encuentran?

  4. Otros "usuarios finales" que informan problemas es el mecanismo de detección real final y seamos honestos, un buen malware no le permitirá al usuario saber que hay un problema hasta que sea demasiado tarde para hacer una diferencia. El malware bien escrito no va a voltear su pantalla o robar todo su ancho de banda, sino que se quedará allí en segundo plano, registrando todos sus datos bancarios antes de publicarlos en algún volcado anónimo en alguna parte.

Todo el proceso depende de proyectos aguas arriba para mantener sus propios niveles de seguridad. Si alguien pasó algo por encima del mantenedor de la calculadora Gnome, es probable que todos se lo pierdan en el futuro. Un equipo de seguridad nunca lo sospechará tampoco.

Afortunadamente, la mayoría de los mantenedores son buenos en lo que hacen. Conocen su base de código y si no entienden los parches, los rechazarán porque no son lo suficientemente claros.

En términos de evaluación de riesgos, al usar algo que es mucho menos popular, es probable que haya menos ojos revisando el código. Pero de manera similar, probablemente haya menos commits, por lo que siempre que el mantenedor no sea flojo (o malvado), podría tener más tiempo para lidiar con cada commit. Es difícil decir exactamente cuánto riesgo corres. La seguridad del software de código abierto depende de personas capaces que miren el código.

Por el contrario, los elementos de origen cerrado (en los repositorios de socios y compras) no son auditados por la comunidad. Canonical puede tener algún acceso a la fuente, pero francamente dudo que tengan los recursos para realizar auditorías exhaustivas incluso si tuvieran acceso a la fuente y quisieran.

De manera similar con los PPA, obtienes muy poca protección a menos que quieras sumergirte en la fuente tú mismo. Los usuarios pueden agregar lo que quieran al código fuente y, a menos que lo revisen ustedes mismos (y sean capaces de detectar malware), son una oveja rodeada de lobos. Las personas pueden informar malos PPA, pero algo sucede depende de que otras personas verifiquen y confirmen el problema. Si un sitio grande (por ejemplo, OMGUbuntu) recomienda un PPA (como lo hacen a menudo), muchos usuarios pueden tener problemas en el futuro.

Para agravar el problema, la menor cuota de mercado de los usuarios de Linux significa que hay menos software disponible para que busquemos códigos incorrectos. Odio decirlo, pero al menos con Windows, hay docenas de compañías que pasan todos los días hábiles, descubriendo cómo funciona el mal software, cómo detectarlo y cómo eliminarlo. Ese fue un mercado nacido de la necesidad y aunque odio decir esto también, las cosas probablemente empeorarán aquí antes de mejorar.

Para los paranoicos de seguridad, escribí un breve artículo hace un tiempo: Linux no es invulnerable. No digas que lo es. . Introducir cosas en el repositorio probablemente no será el principal vector de ataque para los imbéciles que distribuyen malware. Es mucho más probable (IMO) que jueguen con la avaricia y la estupidez de los usuarios para que instalen .debs infectados.


3
Lo bueno de los repositorios examinados es que generalmente son órdenes de magnitud más seguros que la instalación de software en un modelo sin repositorio, como instalar cualquier cosa desde un exe. Entonces, sí, nunca estás a salvo. Pero en general, probablemente estés más seguro.
Kzqai

¿Querías escribir? ¿Qué sucede si alguien revela un agujero que encuentra ?
tshepang

25

Sí. La comunidad verifica los paquetes (por lo tanto, 1 podría instalar algún malware, pero esa noticia se difundirá rápidamente entre todos los usuarios).

Las aplicaciones deben cumplir con reglas muy estrictas descritas en las licencias .

La página wiki para nuevos paquetes tiene un poco más de información:

Pasando por MOTU

Los paquetes que aún no están en Ubuntu requieren un escrutinio adicional y pasan por un proceso de revisión especial, antes de que los administradores de archivos carguen y obtengan una revisión final . Puede encontrar más información sobre el proceso de revisión, incluidos los criterios que se aplicarán, en la página Revisores de código . Se alienta a los desarrolladores a examinar sus propios paquetes utilizando estas pautas antes de enviarlos para su revisión.

Para recibir informes de errores de mayor calidad, escriba un enlace de apport para su paquete.

Dicho esto: la idea general es. Si encuentra algo sospechoso, lo informa en launchpad, askubuntu, ubuntuforums y alguien lo recogerá.

Lo que podría suceder es que un creador de malware crea un paquete válido, lo acepta y luego realiza una actualización que agrega el malware. Al menos uno de los muchos siempre atrapa esto y él / ella lo informará en alguna parte. No va a entrar en muchas máquinas de esta manera. (el esfuerzo de conseguirlo en nuestras máquinas es demasiado para la recompensa potencial: apuntar a las máquinas con Windows es mucho más fácil).

Ejemplo de cosas que van terriblemente mal con el abejorro . Alguien perdió un espacio y / usr fue eliminado ... algunas personas se vieron afectadas, 1 publica una advertencia con banderas rojas y ahora todos lo sabemos. El creador lo repara (más rápido que la velocidad de la luz) pero el daño se hizo en varios sistemas. Y esto fue un error y no deliberado para que pueda suceder;)


44
Cabe señalar que existe algún riesgo relacionado con otras fuentes que se integran al Centro de software de Ubuntu, como Getdeb o varios PPA. Sin embargo, si no los usa, debe estar seguro.
jnv

@jnv good call :) Cambié la primera línea y ahora también incluye ppas;)
Rinzwind

Tu ejemplo no es válido. abejorro no está presente en los repositorios.
Lincity

Estoy en desacuerdo. Cualquier cosa que se instale se evalúa por igual: los usuarios realizan la comprobación, por lo que es un ejemplo válido de que algo accidentalmente (!) Sale mal. Por lo tanto, hacerlo a propósito también es posible, pero lo que debe enfocarse es que los usuarios le digan a los demás que tiene una falla. No es el defecto en sí;)
Rinzwind

La pregunta era sobre el centro de software.
Lincity

5

Supongo que nadie puede asegurarte eso. Tendría que verificar qué tiene que suceder para que un paquete se agregue al índice de paquetes de Debian, pero creo que debería poder introducir algo mal allí.

Puede configurar una máquina virtual y probar el software allí, luego puede ver el tráfico de la red con algo así como iftoppara ver si esta aplicación se comunica con el hogar. Lo más probable es que nunca veas nada porque está oculto demasiado bien.

El código abierto no significa seguridad, solo porque pueda ver el código no significa que alguien lo haya hecho.


2

Para publicar código en un PPA en la plataforma de lanzamiento, debe configurar openPGP y crear una clave adjunta a una dirección de correo electrónico. Para firmar un paquete, necesita una copia de la clave privada en la máquina local y la contraseña (que no se almacena en ningún lugar). Si un paquete tiene problemas de seguridad, debería ser relativamente fácil localizar al autor. Supongo que los repositorios principales para Ubuntu y Debian son al menos tan seguros.

La mayoría de los proyectos de código abierto tienen un repositorio central con al menos un nivel de protección ssh (contraseña y / o par de claves pública / privada). Obtener acceso no autorizado aquí es un poco más fácil que el ppa pero no es trivial. Los sistemas de versiones generalmente registran al usuario que realiza cada confirmación y hacen que sea bastante fácil descubrir qué hace una confirmación.

Uno siempre podría intentar colocar algo en un parche, pero esta es una propuesta arriesgada. La mayoría de los codificadores no aceptarán un parche que sea demasiado grande para leer fácilmente. Si te atrapan, eso es todo.

Todavía hay una cierta cantidad en la que se puede confiar, por lo que es posible que alguien pueda obtener spyware en Ubuntu. Tal vez sea algo de lo que tendremos que preocuparnos si la cuota de mercado de Ubuntu crece significativamente.


Cualquier persona puede inventar una clave GPG. Podría configurar una máquina virtual, generar una clave con un nombre falso y nadie sería más sabio. Tienes que buscar la red de confianza para juzgar realmente el GPG, e incluso eso no es canónico.
Martin Ueding
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.