Malwares via wine
Résolu
Bonsoir à tous,
J'ai quelqu'un qui a utilisé mon micro et qui a téléchargé et installé via wine 3 malwares (babylon, playerplus, pricegong). D'ailleurs wine ne demande pas le mot de passe root avant d'installer quoi que ce soit...
Bon bref, comme ils sont non désinstallables (et que les outils pour les désinstaller ne sont disponibles que sous windows), j'ai carrément désinstallé wine (je ne m'en sers pas) et tué tous les processus .exe. (Je verrai au redémarrage s'ils reviennent ou non.)
Deux d'entre eux m'ont quand même installé des fichiers .desktop (supprimés aussi)
Je voudrais savoir si le fait qu'ils aient créé les .desktop signifie qu'ils sont actifs sous linux, et si la désinstallation de wine suffit à éliminer ces trucs.
Merci.
J'ai quelqu'un qui a utilisé mon micro et qui a téléchargé et installé via wine 3 malwares (babylon, playerplus, pricegong). D'ailleurs wine ne demande pas le mot de passe root avant d'installer quoi que ce soit...
Bon bref, comme ils sont non désinstallables (et que les outils pour les désinstaller ne sont disponibles que sous windows), j'ai carrément désinstallé wine (je ne m'en sers pas) et tué tous les processus .exe. (Je verrai au redémarrage s'ils reviennent ou non.)
Deux d'entre eux m'ont quand même installé des fichiers .desktop (supprimés aussi)
Je voudrais savoir si le fait qu'ils aient créé les .desktop signifie qu'ils sont actifs sous linux, et si la désinstallation de wine suffit à éliminer ces trucs.
Merci.
A voir également:
- Malwares via wine
- Wine chromebook - Télécharger - Émulation & Virtualisation
- Via michelin carte - Télécharger - Transports & Cartes
- Anti malwares - Télécharger - Antivirus & Antimalwares
- Partager des photos via un lien - Guide
- ViaMichelin - Télécharger - Transports & Cartes
5 réponses
D'ailleurs wine ne demande pas le mot de passe root avant d'installer quoi que ce soit...
???
Depuis quand wine a besoin de ton mot de passe root ?
Je voudrais savoir si le fait qu'ils aient créé les .desktop signifie qu'ils sont actifs sous linux, et si la désinstallation de wine suffit à éliminer ces trucs.
Dans l'absolu oui car normalement un environnement wine est cantonné à une arborescence restreinte (typiquement ~/.wine/, ou ~ désigne ton dossier personnel, par exemple /home/mando/.wine si ton utilisateur s'appelle mando). Il peut ensuite atteindre d'autres parties de l'arborescence linux en fonction des lecteurs que tu as déclaré dans wine.
Exemple : ci-dessous, wine référence trois disques, c: d: et z:qui pointent respectivement sur ~/.wine/dosdevice/drive_c, /media/iso-ft et /).
Si tu as référencé / en tant que lecteur dans wine (comme c'est le cas dans mon exemple avec z:), rien n'empêche d'imaginer qu'il y a lu ou écrit des données (en fonction des droits avec lesquels wine a été lancé) n'importe où. Il faudrait regarder quelles parties de l'arborescence linux étaient accessibles depuis wine. Si wine a été lancé en utilisateur, a priori les droits linux sont configurés de sorte à ce que seuls /home/mando ait été potentiellement altéré, car c'est le seul endroit où mando peut écrire (avec /tmp).
Si tu as lancé wine en root (ce que tu n'es jamais sensé faire en pratique) il peut potentiellement s'être passé n'importe quoi, car root peut tout faire. Il est assez facile de vérifgier si wine a été lancé en root (si ~root/.wine = /root/wine existe).
Par ailleurs, supprimer le paquet wine ne fait que supprimer wine du système, mais pas le profil wine. Ainsi si les utilisateurs tata, titi et toto ont utilisé wine, ~tata/.wine ~toto/.wine et ~titi/.wine ne sont pas supprimés lorsque tu désinstalles wine.
Bonne chance
???
Depuis quand wine a besoin de ton mot de passe root ?
Je voudrais savoir si le fait qu'ils aient créé les .desktop signifie qu'ils sont actifs sous linux, et si la désinstallation de wine suffit à éliminer ces trucs.
Dans l'absolu oui car normalement un environnement wine est cantonné à une arborescence restreinte (typiquement ~/.wine/, ou ~ désigne ton dossier personnel, par exemple /home/mando/.wine si ton utilisateur s'appelle mando). Il peut ensuite atteindre d'autres parties de l'arborescence linux en fonction des lecteurs que tu as déclaré dans wine.
Exemple : ci-dessous, wine référence trois disques, c: d: et z:qui pointent respectivement sur ~/.wine/dosdevice/drive_c, /media/iso-ft et /).
(mando@aldur) (~/.wine/dosdevices) $ ls -l total 0 lrwxrwxrwx 1 mando mando 10 août 2 2011 c: -> ../drive_c lrwxrwxrwx 1 mando mando 14 août 2 2011 d: -> /media/iso-ft/ lrwxrwxrwx 1 mando mando 1 août 2 2011 z: -> /
Si tu as référencé / en tant que lecteur dans wine (comme c'est le cas dans mon exemple avec z:), rien n'empêche d'imaginer qu'il y a lu ou écrit des données (en fonction des droits avec lesquels wine a été lancé) n'importe où. Il faudrait regarder quelles parties de l'arborescence linux étaient accessibles depuis wine. Si wine a été lancé en utilisateur, a priori les droits linux sont configurés de sorte à ce que seuls /home/mando ait été potentiellement altéré, car c'est le seul endroit où mando peut écrire (avec /tmp).
Si tu as lancé wine en root (ce que tu n'es jamais sensé faire en pratique) il peut potentiellement s'être passé n'importe quoi, car root peut tout faire. Il est assez facile de vérifgier si wine a été lancé en root (si ~root/.wine = /root/wine existe).
ls -l ~root/.wine
Par ailleurs, supprimer le paquet wine ne fait que supprimer wine du système, mais pas le profil wine. Ainsi si les utilisateurs tata, titi et toto ont utilisé wine, ~tata/.wine ~toto/.wine et ~titi/.wine ne sont pas supprimés lorsque tu désinstalles wine.
Bonne chance
Justement, j'avais jamais fait gaffe à ça, mais ce serait bien que toute installation de logiciel via wine soit faite avec un mot de passe (pas fatalement root), ça éviterai au "je-clique-partout-je télécharge-n'importe-quoi" de faire des conn*****.
Pour le reste, j'ai effacé le fichier .wine, justement donc pas trop de problèmes de ce côté là. Je vais quand même jeter un coup d'oeil au /home voir s'il y a d'autres trucs qui traînent.
(Et non, je n'ai jamais lancé wine en root). Par contre, y'at'il un moyen d'empêcher un utilisateur d'accèder à tel ou tel logiciel / de régler finement les permissions ?
Merci en tout cas pour les explications.
Pour le reste, j'ai effacé le fichier .wine, justement donc pas trop de problèmes de ce côté là. Je vais quand même jeter un coup d'oeil au /home voir s'il y a d'autres trucs qui traînent.
(Et non, je n'ai jamais lancé wine en root). Par contre, y'at'il un moyen d'empêcher un utilisateur d'accèder à tel ou tel logiciel / de régler finement les permissions ?
Merci en tout cas pour les explications.
Justement, j'avais jamais fait gaffe à ça, mais ce serait bien que toute installation de logiciel via wine soit faite avec un mot de passe (pas fatalement root), ça éviterai au "je-clique-partout-je télécharge-n'importe-quoi" de faire des conn*****.
En fait ça n'a pas vraiment de sens car wine ne fait que reproduire une arborescence pseudo windows dans un compte utilisateur. La notion de root n'a donc pas de sens, car "installer un programme sous wine" ne revient qu'à pipoter un programme windows et créer des fichiers dans le home de l'utilisateur. C'est un peu comme si tu disais "quand un utilisateur veut installer une extension firefox, le mot de passe root devrait être demandé". La seule règle, c'est de ne jamais lancer wine en root.
Et non, je n'ai jamais lancé wine en root). Par contre, y'at'il un moyen d'empêcher un utilisateur d'accèder à tel ou tel logiciel / de régler finement les permissions ?
Oui tu peux par exemple utiliser des acl. L'idée serait alors de retirer les droits en exécution à /usr/bin/wine à toto si toto ne doit pas pouvoir lancer wine. Mais comme je te disais ça n'a pas vraiment d'intérêt, car toto n'a a priori que les droits pour altérer /home/toto, même s'il à configurer un lecteur de disque wine qui pointe sur /. Ainsi il ne peut "pourrir" que ses propres fichiers (et après tout, c'est son droit :p).
Dans ton cas, le problème ne t'aurait pas impacté si tu avais créé un compte à la personne à qui tu as prêté ton PC, il aurait fait n'importe quoi au niveau de son home sans perturber le tien.
Concrètement s'il a lancé wine avec ton compte et que ton login est tata, alors seuls les fichiers situés dans /home/tata ont pu être altérés. A priori s'il n'a rien configuré dans wine il est même probable que ça n'est impacté que /home/tata/.wine... Du coup il suffirait de supprimer ce répertoire pour repartir sur des bases saines (via ton explorateur de fichier, nautilus ou doplhin par exemple, et après avoir affiché les fichiers cachés).
Bonne chance
En fait ça n'a pas vraiment de sens car wine ne fait que reproduire une arborescence pseudo windows dans un compte utilisateur. La notion de root n'a donc pas de sens, car "installer un programme sous wine" ne revient qu'à pipoter un programme windows et créer des fichiers dans le home de l'utilisateur. C'est un peu comme si tu disais "quand un utilisateur veut installer une extension firefox, le mot de passe root devrait être demandé". La seule règle, c'est de ne jamais lancer wine en root.
Et non, je n'ai jamais lancé wine en root). Par contre, y'at'il un moyen d'empêcher un utilisateur d'accèder à tel ou tel logiciel / de régler finement les permissions ?
Oui tu peux par exemple utiliser des acl. L'idée serait alors de retirer les droits en exécution à /usr/bin/wine à toto si toto ne doit pas pouvoir lancer wine. Mais comme je te disais ça n'a pas vraiment d'intérêt, car toto n'a a priori que les droits pour altérer /home/toto, même s'il à configurer un lecteur de disque wine qui pointe sur /. Ainsi il ne peut "pourrir" que ses propres fichiers (et après tout, c'est son droit :p).
Dans ton cas, le problème ne t'aurait pas impacté si tu avais créé un compte à la personne à qui tu as prêté ton PC, il aurait fait n'importe quoi au niveau de son home sans perturber le tien.
Concrètement s'il a lancé wine avec ton compte et que ton login est tata, alors seuls les fichiers situés dans /home/tata ont pu être altérés. A priori s'il n'a rien configuré dans wine il est même probable que ça n'est impacté que /home/tata/.wine... Du coup il suffirait de supprimer ce répertoire pour repartir sur des bases saines (via ton explorateur de fichier, nautilus ou doplhin par exemple, et après avoir affiché les fichiers cachés).
Bonne chance
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question