Les programmes dans Ubuntu Software Center sont-ils exempts de logiciels espions?


35

Dans Ubuntu Software center, il existe différentes sections pour les programmes

  • Fourni par Ubuntu
  • Partenaires canoniques
  • Pour achat

Je sais que tous sont open-source; mais y at-il un processus de validation effectué par Canonical pour s’assurer qu’il ne contient aucun spyware ou malware? ?

Je me demande si tout le monde aura le temps de regarder tous ces programmes (2355 programmes ou plus à partir de maintenant), un code de logiciel aussi pour chaque version !!

Je suis inquiet parce que j'installe régulièrement un logiciel plutôt impopulaire à partir du centre logiciel :)


1
Le logiciel "For Purchase" n'est pas une source ouverte, sinon les gens n'auraient pas besoin de l'acheter. Et le logiciel partenaire n'est pas toujours une source ouverte, Skype n'est pas ouvert, par exemple
Martin Ueding, le

8
@queueoverflow, il est possible de faire payer pour un logiciel open source.
dv3500ea

3
@ queueoverflow: qtiplot serait un exemple, les frais pour les fichiers binaires et les contrats de support, vous êtes libre de vous compiler gratuitement. :-)
Christoph

2
Eh bien, je ne pense pas qu’il existe actuellement de logiciel open source dans la section For Purchase, mais il se peut qu’il en existe dans le futur.
dv3500ea

1
@Christoph: Je suppose que la plupart des gens ne savent pas comment le compiler, il est donc logique de le gérer comme ça.
Martin Ueding

Réponses:


27

Existe-t-il un processus pour s'assurer qu'il n'y a pas de malware? Non, il n'y a aucune garantie.

Il existe cependant plusieurs mécanismes pour essayer de le détecter, mais même si je ne veux pas être trop sombre, si vous êtes honnête, vous n'êtes probablement pas aussi en sécurité que vous voudriez l'être.

  1. Un projet doit d'abord être ajouté à Ubuntu. Comme le dit Rinzwind, les vérifications sont effectuées à ce stade, mais ce n’est en réalité que la partie visible de l’iceberg qui constitue la vie d’un paquet dans Ubuntu.

  2. La première véritable ligne de défense pour les paquets à long terme sont leurs responsables de projet. Ces personnes gèrent leurs projets et acceptent des correctifs pour les améliorer. Ils sont humains.Ils font des erreurs et manquent des choses. Et certains pourraient être paresseux.

    Il est possible qu'une personne malveillante passe au-dessus de certains logiciels malveillants en incluant de véritables améliorations avec le logiciel malveillant.

    Si quelque chose de mauvais est admis dans un projet par son responsable, enregistrez un audit réussi, il est probable que le code aboutira sur les machines des utilisateurs Ubuntu.

  3. Les audits de sécurité sont la deuxième étape. Il s’agit d’examiner le code et de l’exécuter sur des moniteurs pour détecter les mauvaises choses. Autant que je sache, il n’existe pas d’équipe officielle de Canonical dédiée à la sécurité, mais deux équipes de communauté (Ubuntu Security et MOTU SWAT) gèrent tous les packages qui les séparent.

    L'audit ne fonctionne vraiment que si chaque ligne de code est vérifiée correctement avant d'être envoyée aux utilisateurs. Ce n'est pas vraiment pratique pour la quantité de code et le nombre de mises à jour dont nous parlons. Cela prendrait énormément de temps et d’argent.

    Il existe une hypothèse dans le monde open source que juste parce que quelqu'un peut consulter le code source. C'est une philosophie très dangereuse à maintenir.

    Les correctifs de sécurité sont en grande partie réactionnaires lorsque les utilisateurs découvrent et révèlent des failles. Qu'advient-il si quelqu'un révèle un trou, ils trouvent?

  4. Les autres utilisateurs signalant des problèmes sont le dernier mécanisme de détection. Soyons honnêtes, un bon logiciel malveillant ne le laissera pas au courant avant qu’il ne soit trop tard pour faire la différence. Les malwares bien écrits ne vont pas retourner votre écran ou voler toute votre bande passante, ils vont rester en arrière-plan, en enregistrant toutes vos coordonnées bancaires avant de les publier quelque part dans un cliché anonyme.

L'ensemble du processus dépend des projets en amont pour maintenir leurs propres niveaux de sécurité. Si quelqu'un passe à côté du responsable de la calculatrice Gnome, il est probable que tout le monde l'aura oublié. Une équipe de sécurité ne le soupçonnera jamais non plus.

Heureusement, la plupart des mainteneurs sont bons dans ce qu'ils font. Ils connaissent leur base de code et s’ils ne comprennent pas les correctifs, ils les refusent parce qu’ils ne sont pas assez clairs.

En termes d’évaluation des risques, en utilisant quelque chose de beaucoup moins populaire, il ya probablement moins d’œil qui vérifie le code. Mais de même, il y a probablement moins de commits, aussi longtemps que le mainteneur n'est pas paresseux (ou diabolique), ils peuvent avoir plus de temps pour traiter chaque commet. Il est difficile de dire exactement combien de risques vous êtes. La sécurité des logiciels Open Source dépend de la capacité des personnes compétentes à consulter le code.

Inversement, les éléments source fermés (dans les comptes de partenaires et d’achat) ne sont complètement pas audités par la communauté. Canonical a peut-être un accès à la source, mais franchement, je doute qu'ils disposent des ressources nécessaires pour procéder à des audits approfondis, même s'ils disposaient d'un accès à la source et le souhaitaient.

De même avec les PPA, vous obtenez très peu de protection à moins de vouloir vous plonger vous-même dans la source. Les utilisateurs peuvent ajouter ce qu'ils veulent au code source et, à moins que vous ne le vérifiiez vous-même (et que vous soyez capable de détecter les logiciels malveillants), vous êtes un mouton entouré de loups. Les gens peuvent signaler de mauvais AAE, mais quelque chose se passe dépend de la vérification et de la confirmation du problème. Si un grand site (par exemple, OMGUbuntu) a recommandé un PPA (comme c'est souvent le cas), de nombreux utilisateurs risquent d'avoir des problèmes en bout de ligne.

Pour aggraver le problème, la part de marché moindre des utilisateurs de Linux signifie que nous disposons d’un peu moins de logiciels pour traquer les codes malveillants. Je déteste le dire, mais au moins avec Windows, vous avez des dizaines d’entreprises qui passent chaque jour de leur travail à découvrir comment un logiciel fonctionne, à le détecter et à le supprimer. C’était un marché né de la nécessité et, même si je déteste dire ça aussi, les choses vont probablement empirer avant de s’améliorer.

Pour les paranoïaques de la sécurité, j'ai écrit un article court il y a quelque temps: Linux n'est pas invulnérable. Ne dis pas que c'est. . Faufiler des choses dans le référentiel ne sera probablement pas le principal vecteur d’attaque pour les asshats qui distribuent des logiciels malveillants. Il est beaucoup plus probable (OMI) qu'ils vont jouer sur la cupidité et la stupidité des utilisateurs pour les amener à installer des .debs infectés.


3
La bonne chose à propos des référentiels approuvés est qu'ils sont généralement beaucoup plus sécurisés d'un ordre de grandeur à une installation logicielle dans un modèle sans référentiel, comme si vous installiez quoi que ce soit à partir d'un fichier exe. Donc, oui, vous n'êtes jamais en sécurité. Mais en général, vous êtes probablement plus en sécurité.
Kzqai

Voulez-vous dire écrire Que se passe-t-il si quelqu'un révèle un trou qu'il trouve ?
Tshepang

25

Oui. Les paquetages sont vérifiés par la communauté (de sorte que 1 peut installer certains logiciels malveillants mais que les nouvelles se propagent rapidement à tous les utilisateurs).

Les applications doivent respecter des règles très strictes définies dans les licences .

La page wiki pour les nouveaux paquets contient un peu plus d'informations:

En passant par MOTU

Les paquets qui ne sont pas encore dans Ubuntu nécessitent un examen approfondi et sont soumis à un processus de révision spécial avant d'être téléchargés et de recevoir une dernière révision par les administrateurs de l' archive . Plus d'informations sur le processus de révision, y compris les critères qui seront appliqués, sont disponibles sur la page Réviseurs de codes . Les développeurs sont invités à examiner leurs propres packages à l'aide de ces instructions avant de les soumettre pour examen.

Pour recevoir des rapports de bogue de qualité supérieure, écrivez un crochet de répartition pour votre paquet.

Cela dit: l'idée générale est. Si vous trouvez quelque chose de suspect, signalez-le sur le tableau de bord, askubuntu, ubuntuforums et quelqu'un le récupérera.

Ce qui pourrait arriver, c’est qu’un créateur de logiciel malveillant crée un package valide, le fait accepter et ensuite effectue une mise à jour qui ajoute le logiciel malveillant. Au moins un parmi beaucoup d’autres s’y prend toujours et il le rapportera quelque part. De cette façon, il ne va pas arriver à beaucoup de machines. (L’effort de l’obtenir sur nos machines est trop lourd pour la récompense potentielle: cibler des machines Windows est beaucoup plus facile).

Exemple de choses qui vont très mal avec bourdon . Quelqu'un a manqué un espace et / usr a été supprimé ... certaines personnes ont été touchées, 1 a affiché un avertissement avec des drapeaux rouges et nous le savons tous maintenant. Creator le corrige (plus rapidement que la vitesse de la lumière) mais plusieurs systèmes ont été endommagés. Et ce fut une erreur et non délibérée pour que cela puisse arriver;)


4
Il convient de noter qu’il existe certains risques liés à d’autres sources qui s’intègrent à Ubuntu Software Center, telles que Getdeb ou divers PPA. Cependant, si vous ne les utilisez pas, vous devriez être en sécurité.
JNV

@jnv good call :) J'ai changé la 1ère ligne et cela inclut désormais les ppas aussi;)
Rinzwind

Votre exemple est invalide. bumblebee n'est pas présent dans les pensions.
Lincity

Je ne suis pas d'accord. Tout ce qui est installé est évalué de la même manière: les utilisateurs procèdent à la vérification. Il s’agit donc d’un exemple valide d’une erreur (!) Accidentelle. Il est donc également possible de le faire exprès, mais il est essentiel que les utilisateurs disent aux autres qu'ils ont un défaut. Pas la faille elle-même;)
Rinzwind

la question portait sur le centre de logiciel.
Lincity

5

Je suppose que personne ne peut vous assurer que. Il vous faudrait vérifier ce qui doit se passer pour qu'un paquet soit ajouté à l'index des paquets Debian, mais je pense que vous devriez pouvoir y insérer quelque chose de mal.

Vous pouvez configurer une machine virtuelle et essayer le logiciel à cet endroit. Vous pouvez ensuite examiner le trafic réseau iftoppour voir, par exemple, si cette application communique avec le domicile. Il y a des chances pour que vous ne voyiez jamais rien car il est trop bien caché.

Open Source ne signifie pas sécurité, le simple fait de consulter le code ne signifie pas que quelqu'un l'a fait.


2

Afin de publier le code dans un PPA sur le tableau de bord, vous devez configurer openPGP et créer une clé associée à une adresse e-mail. Pour signer un colis, vous devez disposer d'une copie de la clé privée sur l'ordinateur local et du mot de passe (qui n'est stocké nulle part). Si un paquet a des problèmes de sécurité, il devrait être relativement facile de localiser l'auteur. Je suppose que les référentiels principaux pour Ubuntu et Debian sont au moins aussi sécurisés.

La plupart des projets open source ont un référentiel central avec au moins une protection de niveau ssh (mot de passe et / ou paire de clés publique / privée). Obtenir un accès non autorisé ici est un peu plus facile que le PPA mais pas trivial. Les systèmes de gestion de versions enregistrent généralement l'utilisateur qui effectue chaque validation et rendent assez facile la tâche de savoir ce que fait une validation.

On pourrait toujours essayer de glisser quelque chose dans un patch mais c'est une proposition risquée. La plupart des codeurs n'accepteront pas un patch trop volumineux pour être lu facilement. Si vous êtes pris, c'est à peu près tout.

Il reste encore un certain montant à faire confiance, de sorte qu'il est possible que quelqu'un introduise un logiciel espion dans Ubuntu. Nous devrons peut-être nous inquiéter de cela si la part de marché d'Ubuntu augmente de manière significative.


Une clé GPG peut être composée par n'importe qui. Je pourrais configurer une machine virtuelle, générer une clé avec un faux nom et personne ne serait le plus sage. Il faut rechercher le réseau de confiance pour vraiment juger le GPG, et même cela n’est pas canonique.
Martin Ueding
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.