Archlinux.fr [Forums]

Ne croyez pas que ça soit spécifique à Ubuntu. N'importe qui peut uploader un paquet sur AUR qui détruit votre système ou le transforme en esclave d'un botnet.

Alors SVP, pensez à lire les PKGBUILD et les fichiers .install quand vous installez des paquets depuis AUR, même quand vous utilisez Yaourt. Je vois beaucoup trop de gens qui ne le font pas sur ce forum.

Au passage, ça peut aussi arriver avec un miroir si l'admin est corrompu tant qu'on n'a pas le package signing, mais pour ça on n'a pas d'autre choix que de leur faire confiance actuellement.

La rançon du succès
Ça peut malheureusement même arriver en dehors des miroirs ou PKGBUILD, un soft peu connu sera par définition moins analysé

Oui, après les gens qui packagent sont censés vérifier que le logiciel qu'ils fournissent n'est pas malveillant, mais évidemment ce n'est pas forcément toujours fait.

Bonjour, les liens du script ainsi que le thème venant de gnome-look ont été effacé, je me demande si ça avait été un programme windows (screensaver infecté), le programme serait encore sur le site?

à mon avis quand tu installes un programme, script et autre tu vérifies la provenance, les retours d'utilisateurs, la popularité et le nombre de téléchargement.

Personnellement je vérifie le paquet s'il n'a pas beaucoup de vote... Car sérieusement, il faudrait aussi vérifier que le miroir du svn ou autre correspond bien avec la source du logiciel d'origine... Mais bon c'est vrai cela prend trop de temps...

Vous avez déjà rencontré des cas de malveillances via AUR ?

Le problème pour moi n'est pas de lire le PKGBUILD, c'est de le comprendre

La sagesse voudrait donc que j'évite d'utiliser AUR mais Arch perdrait grandement de son intérêt…

Lunatic a écrit :Le problème pour moi n'est pas de lire le PKGBUILD, c'est de le comprendre

Bingo ! Même souci pour moi.
Si le PKGBUILD contient un beau rm -fr /, je m'en rendrais compte.
Mais si la commande malveillante est plus « exotique », je risque de ne pas la voir.

Jusqu'à présent, je n'ai rencontré aucune malveillance sur AUR.
À moins qu'il n'y ait eu des malveillances que je n'ai pas détectées, et que j'ai installées ...

Le PKGBUILD est inoffensif en lui même, mais si tu compile un programme pour devoir l'exécuter en root après ... Il faudrait regarder les sources... Autant ne pas l'installer alors...
Non ce qui est vraiment dangereux c'est les .install, car eux s'exécute en root quand tu installes le paquet..

benjarobin a écrit :Le PKGBUILD est inoffensif en lui même

ça dépend, il est sourcé par makepkg (et donc par yaourt et cie) et toute commande est exécutée, donc faire gaffe quand même.
yaourt propose de l'éditer avant de le sourcer.

Lunatic a écrit :Le problème pour moi n'est pas de lire le PKGBUILD, c'est de le comprendre

Vinvin a écrit :Si le PKGBUILD contient un beau rm -fr /, je m'en rendrais compte.
Mais si la commande malveillante est plus « exotique », je risque de ne pas la voir.

Le tout est de détecter un truc anormal, un pkgbuild, c'est un ensemble de variables + une fonction build (ou plusieurs fonctions si c'est des paquets splittés), il ne devrait y avoir aucune commande en dehors qui traîne et les fonctions sont exécutées à l'intérieur d'un fakeroot, donc en fait, il suffit juste de vérifier qu'il n'y a pas de lignes orphelines, et traquer les `` ou $()

Pour le fichier .install, c'est autre chose, mais on peut comparer à des paquets dits sûr du même genre, si par exemple un paquet d'icônes contient autre choses qu'un "gtk-update-icon-cache", on peut se poser des questions.

Oui enfin je peux te faire un PKGBUILD et même toi (enfin je pense a moins d'être un fou de l'informatique^^) tu ne t'en rendra pas compte que j'ai mis un virus dedans.
Je ne sais pas si c'est une bonne idée d'expliquer comment on pourrait tromper un user avancée.

Le PKGBUILD compile un programme normal (on récupère les sources depuis un svn) On récupère un patch depuis un autre site qui a parait 'sure'. On compile le tout... On creer en faite en plus le 'virus'. On nomme le virus avec une commande très proche de gtk-update-icon-cache par exemple. Dans le .install on exécute la commande et voila...

Il faudrait vérifier exactement le nom de la commande du .install (qui va le faire ?) Et vérifier le code source du 'patch'

pas faux mais pas aussi simple, le script devra modifier le PATH parce qu'il ne peut pas écraser un fichier existant (bon après il peut le mettre dans un répertoire mieux placé dans la liste )
moralité: utiliser les chemins absolus dans les .install et sans le premier "/"

sinon, c'est clair que je vais pas lire les sources des softs, ceci dit, je vérifies les sources quand même :p mais juste pour voir s'ils pointent à un endroit que je considère de confiance.

La lisibilité décourage déjà l'auteur de faire des crasses, c'est le principe !
Aller sur le site du projet en suivant le lien url= (généralement utile de toute façon) et lire vite fait build() me suffit...

A qui profiterait le crime ? Si on met un pkgbuild sur AUR c'est par besoin, pas par méchanceté. Pour l'instant je trouve qu'il n'y a "rien à craindre" tant qu'on regarde un peu ce qu'on installe.
Il serait assez dur de faire un pkgbuild qui lance des programmes, car il ne peut que mettre des fichiers sur le disque, et ils ne peuvent pas être en conflit avec ceux déjà installés !!
Le seul danger est si (pas comme moi) on a cron et qu'un truc est placé dans /etc/cron.

Un bon tas d'obstacles à une sale blague.

J'ai envie de dire que debian (apt plutôt) est plus perméable à ce genre de coup douteux, vu que c'est un peu "usine à gaz à .install" ; en plus pour faire les paquets faut se faire l'équivalent de notre $pkgdir à la main, leur dpkg ne s'occupe pas de la compile...

Tout ça pour dire qu'avec arch s'il y a un danger c'est dans les .install et les sources elles-mêmes.
On en revient donc au problème général des logiciels libres sur la relecture des sources ; quant au .install c'est très rapide à vérifier !

J'ai pas trop peur sur les sources ; le pot aux roses est très rapidement découvert là où il y a de l'enjeu. (sur les applis très utilisées)

j'apprécie beaucoup le fait d'avoir un PKGBUILD qui se suffit à lui tout seul pour installer un logiciel complet, et c'est dommage que trop souvent on trouve un .install qui ne serve que pour rajouter un commentaire lors de l'installation du paquet généré. Ce n'est pas possible de l'insérer autrement ?

De plus, au niveau de la sécurité, je dois avouer que quand je vois qu'un PKGBUILD a plusieurs commentaires et qu'il est correctement maintenu (mis à jour récemment par exemple), je fais confiance à l'auteur et je ne vérifie pas chaque ligne de son PKGBUILD. Le seul risque (à part une boulette involontaire) est que l'auteur ait abandonné son PKGBUILD récemment et que quelqu'un de non recommandable l'ait adopté récemment (et encore, cela voudrait dire que l'on est dans les premiers à en pâtir)

Calimero a écrit : J'ai envie de dire que debian (apt plutôt) est plus perméable à ce genre de coup douteux, vu que c'est un peu "usine à gaz à .install" ; en plus pour faire les paquets faut se faire l'équivalent de notre $pkgdir à la main, leur dpkg ne s'occupe pas de la compile...

dpkg, c'est l'équivalent de pacman - apt-get, et pacman non plus ne s'occupe pas de la compile, par contre le dpkg-buildpackage serait un peu l'équivalent de makepkg, quant au PKGBUILD, on peut le comparer au fichier debian/{rules,control} pour un .deb
En gros, c'est un peu du pareil au même, à la différence que les paquets deb gèrent bien plus de choses, au pif, les menus, la doc, les liens pour par exemple gérer les alternatives etc...

au final pour du binaire, pacman, apt ou peu importe, tu ne peux pas savoir ce que ça fait, et pour les description des paquets, plus le gestionnaire fait de choses, moins il est simple de tout vérifier, mais heureusement qu'on a pas à tout vérifier, sinon, on utiliserait même pas d'ordis :p