Les journaux sont destinés à des informations qui ne sont pas suffisamment intéressantes
pour être validées en dépêche (sinon n'hésitez pas à proposer votre information en
dépêche), qui sont sans rapport avec Linux ou le libre, ou simplement pour donner votre
avis. Si vous désirez poser une question, merci d'utiliser Derniers journaux de lilliput :
- [11/11@23:00] Webcam Streaming: vlc et Jabber
- [08/11@12:08] Recherche: Proxy applicatif
--> The file /usr/lib/win32/vp31vfw.dll is infected with the W32/Magistr.a@MM virus!
~/wine/C/soft/Setup/COMPLINC.DLL ; advpack.dll ; DECO_32.DLL
Bon certes c'est des dll et je tourne sur linux. Ce qui m'inquiete c'est que plusieurs dll ont été contaminé.
la description du virus se trouve ici :
http://vil.nai.com/vil/content/v_99040.htm(...)
Ce n'est pas un troll. Je me sert de wine uniquement pour un dictionnaire/traducteur. Je n'ai pas encore regarder si vp31vfw.dll etait utilisé par wine ou pas.
> Lire le journal (15 commentaires, moyenne: 3,4).
vp31
Pour information le vp31 est un codec video, et mplayer se sert généralement des codecs présents dans /usr/lib/win32/ (utilisation des dll windows quand pas le choix).
http://www.mplayerhq.hu/DOCS/README(...)
"MPlayer and libavcodec have builtin support for the most common audio and video
formats, but some formats require external codecs. Examples include Real, Indeo
and QuickTime audio formats.
...
The default directory is /usr/local/lib/codecs/ (it used to be
/usr/local/lib/win32 in the past, this also works)"
\_o<
ben...
à la limite, wine peut très bien exécuter un virus qui n'est autre qu'un programme WIN32 normal (ou un script, ou quelque chose s'y rapprochant).
après, de la à modifier les DLL dans /usr/lib/win32, je suis surpris aussi, mais faudrait voir les droits de ces dll...
-
[^]Re: ben...
Posté par lilliput (page perso, ) le 14/11/2004 à 11:43. (lien). Évalué à 2.y'a un blême ..
j'execute jamais wine en tant que root (à moins que ca mets échapper)
-rw-r--r-- 1 root root 462848 2004-09-30 07:45 /usr/lib/win32/vp31vfw.dll
je vais regarder si le pacquage n'est pas véroler à la base après tout on sait jamais.-
[^]Re: ben...
Posté par lilliput (page perso, ) le 14/11/2004 à 12:23. (lien). Évalué à 4.après reinstallation complete du paquet toujours meme erreur.
Je vais envoyer un mail à l'auteur-
[^]Re: ben...
Posté par Sylvain Rampacek (Jabber id, page perso, ) le 14/11/2004 à 12:50. (lien). Évalué à 4.si c'est ça, ça sent effectivement l'infection dans la paquet de base...
-
-
Faux positif
Je viens de tester avec un autre anti-virus. ils se pourrait que ca soit un faux positif;
clamav me dit que c ok.
je vais tester fprot de ce pas.
l'anti-virus utilisé etait aegis-virus-scanner
-
[^]Re: Faux positif
Posté par lilliput (page perso, ) le 14/11/2004 à 13:29. (lien). Évalué à 7.c'est bien un faux positif. désolé de ne pas avoir vérifié avant.
Comme dirai l'autre le user est le premier virus du system..
Il agit de facon stupide et ses réactions peuvent etre imprévisible ou bugger.
Je suis mon virus dans ma matrice ;)-
[^]Re: Faux positif
Posté par Ramso (page perso, ) le 15/11/2004 à 12:35. (lien). Évalué à 2.Et en plus il répand ses bêtises. :-)
--
Groar !
-
Limite du champ d'action de wine
Est ce que wine peux ecrire plus loin que le fake windows drive ?
-
[^]Re: Limite du champ d'action de wine
Posté par Matthieu C () le 14/11/2004 à 14:42. (lien). Évalué à 5.oui, il met arriver de passer a un prog en ligne de commande un chemin unix et ca a marche...
-
[^]Re: Limite du champ d'action de wine
Posté par pasPierre pasTramo () le 14/11/2004 à 15:47. (lien). Évalué à 2.Donc si jamais un virus est executé par wine , il pourrais effacer des fichiers de $HOME.
Meme si de tels virus n'existent pas, vu qu'ils ne sont prevu que pour s'executer dans un environement windows.-
[^]Re: Limite du champ d'action de wine
Posté par yxorp () le 14/11/2004 à 16:49. (lien). Évalué à 5.Même si cela est possible, c'est tellement plus simple de faire un virus natif pour Linux (e.g. script shell, etc.) ... Je veux dire par là que le répertoire personnel d'un utilisateur n'est pas plus (ou si peu) protégé sous Linux que sous Windows contre l'effacement de ses fichiers par un programme que pourrait potentiellement exécuter ce même utilisateur. Si vous avez réussi à lire l'indigeste phrase précédente d'un seul trait, je vous applaudis à deux mains sur mon clavier, avec toutes mes excuses aussi. L'émulateur Windows ne fait donc qu'offrir de nouveaux langages de script exploitables (et exploités) pour créer ce type de virus, mais ça n'a rien de révolutionnaire : des virus de ce type existent déjà parfaitement sans cela.
-
[^]Re: Limite du champ d'action de wine
Posté par Beurt (page perso, ) le 14/11/2004 à 22:22. (lien). Évalué à 4.Je veux dire par là que le répertoire personnel d'un utilisateur n'est pas plus (ou si peu) protégé sous Linux que sous Windows (...)
Il faut quand même rendre le script exécutable avant, ce qui n'est pas une manipulation anodine !-
[^]Re: Limite du champ d'action de wine
Posté par yxorp () le 15/11/2004 à 18:35. (lien). Évalué à 2.Je veux dire par là que le répertoire personnel d'un utilisateur n'est pas plus (ou si peu) protégé sous Linux que sous Windows (...)
Il faut quand même rendre le script exécutable avant, ce qui n'est pas une manipulation anodine !
Que nenni. D'abord, tu n'as cité que le début de ma phrase (...), revoici donc la version intégrale :
Je veux dire par là que le répertoire personnel d'un utilisateur n'est pas plus (ou si peu) protégé sous Linux que sous Windows contre l'effacement de ses fichiers par un programme que pourrait potentiellement exécuter ce même utilisateur.
La phrase est certes un peu longue, mais on comprend bien que dans le cas présent, la manipulation dont tu parles est tout à fait anodine, puisque c'est l'utilisateur lui-même qui pourrait avoir lancé ce script.
Ensuite un script peut tout à fait être exécuté sans avoir recours au moindre droit d'exécution, il suffit d'avoir le droit de lecture dessus et de lancer la commande sh nom_du_script (par exemple pour un script sh).
Enfin, l'utilisateur n'a même pas besoin de lancer cette commande tout seul, pour peu qu'elle ait été placée dans un fichier tel que .login par exemple.-
[^]Pas simple quand même....
Posté par Beurt (page perso, ) le 16/11/2004 à 00:39. (lien). Évalué à 2.Il faut donc de toute façon que l'utilisateur exécute une manipulation qui n'est pas anodine: soit modifier son ".login", soit taper dans un terminal "sh virus_qui_va_tout_me_casser.sh".
En fait lancer un script sous GNU/Linux n'est pas aussi anodin qu'un double clic comme sous d'autres systèmes d'exploitation.
Pour exécuter un script sous GNU/Linux, il faut le vouloir, cela ne risque pas de se produire par hasard; et il faudrait vraiment beaucoup de maladresse pour que ça se produise par erreur (mais c'est pas impossible, certes).
C'était ce que je voulais dire.
NB: si j'avais choisi de ne pas te citer intégralement, c'est que tu reconnaissais toi-même que ta phrase était tortueuse.
-
-
-
-
-
Cette page a été générée par Templeet en 0.0759s (dont 0.0061 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.