ci-après un copier-coller (en anglais) du communiqué d'Intego répercuté
sur MacBidouille.
En résumé, un virus pour Mac circule sous la forme d'un fichier avec
l'extension .mp3
Il s'exécute uniquement si on l'ouvre en double-cliquant dessus.
Faut-il y voir un lien avec une enfilade très récente sur
news://fr.comp.os.mac-os.x?
INTEGO SECURITY ALERT
Intego Announces Protection against the First Mac OS X Trojan Horse:
MP3Concept
Paris, France: 4:15pm, April 8, 2004 - Intego, the Macintosh security
specialist, has just released updated virus definitions for Intego
VirusBarrier to protect Mac users against the first Trojan horse that
affects Mac OS X. This Trojan horse, MP3Concept (MP3Virus.Gen),
exploits a weakness in Mac OS X where applications can appear to be
other types of files.
The Trojan horse's code is encapsulated in the ID3 tag of an MP3
(digital music) file. This code is in reality a hidden application that
can run on any Macintosh computer running Mac OS X.
Mac OS X displays the icon of the MP3 file, with an .mp3 extension,
rather than showing the file as an application, leading users to believe
that they can double-click the file to listen to it. But double clicking
the file launches the hidden code, which can damage or delete files on
computers running Mac OS X, then iTunes to play the music contained in
the file, to make users think that it is really an MP3 file . While the
first versions of this Trojan horse that Intego has isolated are benign,
this technique opens the door to more serious risks.
This Trojan horse has the potential to do any of the following:
- Delete all of a user's personal files
- Send an e-mail message containing a copy of itself to other users
- Infect other MP3, JPEG, GIF or QuickTime files
Due to the use of this technique, users can no longer safely
double-click MP3 files in Mac OS X. This same technique could be used
with JPEG and GIF files, though no such cases of infected graphic files
have yet been seen.
Intego VirusBarrier eradicates this Trojan horse, and Intego remains
diligent to ensure that VirusBarrier will also eradicate any future
viruses that may try to exploit this same technique. All Intego
VirusBarrier users should make sure that their virus definitions are up
to date by using the NetUpdate preference pane in the Mac OS X System
Preferences.
--
Olivier Goldberg, étudiant, macmaniaque, plongeur CMAS ***
Pour le courrier personnel, remplacer dans le From: listes par olivier
AIM/iChat: Nept47
ci-après un copier-coller (en anglais) du communiqué d'Intego répercuté sur MacBidouille.
En résumé, un virus pour Mac circule sous la forme d'un fichier avec l'extension .mp3 Il s'exécute uniquement si on l'ouvre en double-cliquant dessus.
Tres exactement ce qu'il ne faut pas faire avec une piece jointe dans un mail non sollicite ou qui n'explique pas precisemment ce qu'est la piece jointe tout en provenant de quelqu'un que l'on connait.
-- Saïd.
Olivier Goldberg :
Bonsoir,
ci-après un copier-coller (en anglais) du communiqué d'Intego répercuté
sur MacBidouille.
En résumé, un virus pour Mac circule sous la forme d'un fichier avec
l'extension .mp3
Il s'exécute uniquement si on l'ouvre en double-cliquant dessus.
Tres exactement ce qu'il ne faut pas faire avec une piece jointe dans un
mail non sollicite ou qui n'explique pas precisemment ce qu'est la piece
jointe tout en provenant de quelqu'un que l'on connait.
ci-après un copier-coller (en anglais) du communiqué d'Intego répercuté sur MacBidouille.
En résumé, un virus pour Mac circule sous la forme d'un fichier avec l'extension .mp3 Il s'exécute uniquement si on l'ouvre en double-cliquant dessus.
Tres exactement ce qu'il ne faut pas faire avec une piece jointe dans un mail non sollicite ou qui n'explique pas precisemment ce qu'est la piece jointe tout en provenant de quelqu'un que l'on connait.
-- Saïd.
Éric Lévénez
C'est pas vraiment nouveau comme truc. Avec Mac OS X et sa gestion des extensions cachées, des type/créateurs cachés, des icônes modifiables, toute icône montrant un type de fichier peut être en fait un tout autre type de fichier. Si Apple abandonnait les types/créateurs, les extensions cachés et la modification des icônes des fichiers, on aurait un système plus sûr : l'icône d'un document d'une application lancerait cette application.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
C'est pas vraiment nouveau comme truc. Avec Mac OS X et sa gestion des
extensions cachées, des type/créateurs cachés, des icônes modifiables, toute
icône montrant un type de fichier peut être en fait un tout autre type de
fichier. Si Apple abandonnait les types/créateurs, les extensions cachés et
la modification des icônes des fichiers, on aurait un système plus sûr :
l'icône d'un document d'une application lancerait cette application.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
C'est pas vraiment nouveau comme truc. Avec Mac OS X et sa gestion des extensions cachées, des type/créateurs cachés, des icônes modifiables, toute icône montrant un type de fichier peut être en fait un tout autre type de fichier. Si Apple abandonnait les types/créateurs, les extensions cachés et la modification des icônes des fichiers, on aurait un système plus sûr : l'icône d'un document d'une application lancerait cette application.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article <1gby5sb.iw062x10dswl9N%, (Olivier Goldberg) wrote:
Intego VirusBarrier eradicates this Trojan horse, and Intego remains diligent to ensure that VirusBarrier will also eradicate any future viruses that may try to exploit this same technique.
Technique vielle comme le monde (informatique), cf par exemple : http://www.macintouch.com/hotlinetrojan.html#hacktips daté de 1998.
Patrick -- Patrick Stadelmann
In article <1gby5sb.iw062x10dswl9N%listes@ogoldberg.net>,
listes@ogoldberg.net (Olivier Goldberg) wrote:
Intego VirusBarrier eradicates this Trojan horse, and Intego remains
diligent to ensure that VirusBarrier will also eradicate any future
viruses that may try to exploit this same technique.
Technique vielle comme le monde (informatique), cf par exemple :
http://www.macintouch.com/hotlinetrojan.html#hacktips daté de 1998.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1gby5sb.iw062x10dswl9N%, (Olivier Goldberg) wrote:
Intego VirusBarrier eradicates this Trojan horse, and Intego remains diligent to ensure that VirusBarrier will also eradicate any future viruses that may try to exploit this same technique.
Technique vielle comme le monde (informatique), cf par exemple : http://www.macintouch.com/hotlinetrojan.html#hacktips daté de 1998.
Patrick -- Patrick Stadelmann
Patrick Stadelmann
In article <BC9B90BF.6E8CB%, Éric Lévénez wrote:
Si Apple abandonnait les types/créateurs, les extensions cachés et la modification des icônes des fichiers, on aurait un système plus sûr : l'icône d'un document d'une application lancerait cette application.
Non... On peut très bien faire une application dont l'icône est celle d'un fichier MP3.
Patrick -- Patrick Stadelmann
In article <BC9B90BF.6E8CB%news@levenez.com>,
Éric Lévénez <news@levenez.com> wrote:
Si Apple abandonnait les types/créateurs, les extensions cachés et
la modification des icônes des fichiers, on aurait un système plus sûr :
l'icône d'un document d'une application lancerait cette application.
Non... On peut très bien faire une application dont l'icône est celle
d'un fichier MP3.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Si Apple abandonnait les types/créateurs, les extensions cachés et la modification des icônes des fichiers, on aurait un système plus sûr : l'icône d'un document d'une application lancerait cette application.
Non... On peut très bien faire une application dont l'icône est celle d'un fichier MP3.
Patrick -- Patrick Stadelmann
Éric Lévénez
Le 8/04/04 23:39, dans , « Patrick Stadelmann » a écrit :
In article <BC9B90BF.6E8CB%, Éric Lévénez wrote:
Si Apple abandonnait les types/créateurs, les extensions cachés et la modification des icônes des fichiers, on aurait un système plus sûr : l'icône d'un document d'une application lancerait cette application.
Non... On peut très bien faire une application dont l'icône est celle d'un fichier MP3.
Oui bien sûr, c'est justement le problème !!! Mais il faut aussi que l'utilisateur ne lance pas n'importe quoi et cela est vrai sur tout système. Si j'envoie un fichier script avec un bon effacement récursif, par email et si l'utilisateur distant clique sur l'exécutable, alors il se passera des choses pas jolies, que ce soit sous Unix, Linux, Windows, Mac OS X ou Mac OS. Les bidouilles extensions/type/créateur/modif d'icônes peuvent servir trop facilement à faire des chevaux de Troie.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 8/04/04 23:39, dans
<Patrick.Stadelmann-6705BB.23392808042004@news.fu-berlin.de>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
In article <BC9B90BF.6E8CB%news@levenez.com>,
Éric Lévénez <news@levenez.com> wrote:
Si Apple abandonnait les types/créateurs, les extensions cachés et
la modification des icônes des fichiers, on aurait un système plus sûr :
l'icône d'un document d'une application lancerait cette application.
Non... On peut très bien faire une application dont l'icône est celle
d'un fichier MP3.
Oui bien sûr, c'est justement le problème !!! Mais il faut aussi que
l'utilisateur ne lance pas n'importe quoi et cela est vrai sur tout système.
Si j'envoie un fichier script avec un bon effacement récursif, par email et
si l'utilisateur distant clique sur l'exécutable, alors il se passera des
choses pas jolies, que ce soit sous Unix, Linux, Windows, Mac OS X ou
Mac OS. Les bidouilles extensions/type/créateur/modif d'icônes peuvent
servir trop facilement à faire des chevaux de Troie.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 8/04/04 23:39, dans , « Patrick Stadelmann » a écrit :
In article <BC9B90BF.6E8CB%, Éric Lévénez wrote:
Si Apple abandonnait les types/créateurs, les extensions cachés et la modification des icônes des fichiers, on aurait un système plus sûr : l'icône d'un document d'une application lancerait cette application.
Non... On peut très bien faire une application dont l'icône est celle d'un fichier MP3.
Oui bien sûr, c'est justement le problème !!! Mais il faut aussi que l'utilisateur ne lance pas n'importe quoi et cela est vrai sur tout système. Si j'envoie un fichier script avec un bon effacement récursif, par email et si l'utilisateur distant clique sur l'exécutable, alors il se passera des choses pas jolies, que ce soit sous Unix, Linux, Windows, Mac OS X ou Mac OS. Les bidouilles extensions/type/créateur/modif d'icônes peuvent servir trop facilement à faire des chevaux de Troie.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Patrick Stadelmann
In article <BC9B97E6.6E8D9%, Éric Lévénez wrote:
Le 8/04/04 23:39, dans , « Patrick Stadelmann » a écrit :
Non... On peut très bien faire une application dont l'icône est celle d'un fichier MP3.
Oui bien sûr, c'est justement le problème !!!
Mais à part interdire aux applications d'avoir leur propre icônes, je vois pas de solution.
Mais il faut aussi que l'utilisateur ne lance pas n'importe quoi et cela est vrai sur tout système.
A qui le dis-tu :-) Surtout que pour le coup de l'appli qui se déguise en document, il y a un moyen très efficace pour s'apercevoir de la supercherie : la vue par liste et le champ "Kind". Se baser sur l'icône pour identifier un fichier comme un document n'est pas sûr, mais ça ce n'est pas nouveau.
Patrick -- Patrick Stadelmann
In article <BC9B97E6.6E8D9%news@levenez.com>,
Éric Lévénez <news@levenez.com> wrote:
Le 8/04/04 23:39, dans
<Patrick.Stadelmann-6705BB.23392808042004@news.fu-berlin.de>, « Patrick
Stadelmann » <Patrick.Stadelmann@unine.ch> a écrit :
Non... On peut très bien faire une application dont l'icône est celle
d'un fichier MP3.
Oui bien sûr, c'est justement le problème !!!
Mais à part interdire aux applications d'avoir leur propre icônes, je
vois pas de solution.
Mais il faut aussi que
l'utilisateur ne lance pas n'importe quoi et cela est vrai sur tout système.
A qui le dis-tu :-) Surtout que pour le coup de l'appli qui se
déguise en document, il y a un moyen très efficace pour s'apercevoir de
la supercherie : la vue par liste et le champ "Kind". Se baser sur
l'icône pour identifier un fichier comme un document n'est pas sûr, mais
ça ce n'est pas nouveau.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
Le 8/04/04 23:39, dans , « Patrick Stadelmann » a écrit :
Non... On peut très bien faire une application dont l'icône est celle d'un fichier MP3.
Oui bien sûr, c'est justement le problème !!!
Mais à part interdire aux applications d'avoir leur propre icônes, je vois pas de solution.
Mais il faut aussi que l'utilisateur ne lance pas n'importe quoi et cela est vrai sur tout système.
A qui le dis-tu :-) Surtout que pour le coup de l'appli qui se déguise en document, il y a un moyen très efficace pour s'apercevoir de la supercherie : la vue par liste et le champ "Kind". Se baser sur l'icône pour identifier un fichier comme un document n'est pas sûr, mais ça ce n'est pas nouveau.
Patrick -- Patrick Stadelmann
jalon
Éric Lévénez wrote:
C'est pas vraiment nouveau comme truc. Avec Mac OS X et sa gestion des extensions cachées, des type/créateurs cachés, des icônes modifiables, toute icône montrant un type de fichier peut être en fait un tout autre type de fichier. Si Apple abandonnait les types/créateurs, les extensions cachés et la modification des icônes des fichiers, on aurait un système plus sûr : l'icône d'un document d'une application lancerait cette application.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Arf, tu recommences à dire n'importe quoi, mon cher ami... L'extension est toujours visible dans une appli de mail (le fait que l'extension soit cachée étant une propriété propre à un fichier stocké sur un file-system HFS. En gros, pour réaliser une telle chose, il faut encapsuler le pseudo fichier .mp3.app (par exemple) dans une image DMG (ça marche aussi pour une archive non "HFS compliant" mais il faut rajouter des fichiers additionels pour simuler cette propriété, regarder par exemple les archives ZIP produites par le Finder avec unzip -l dans un terminal)
Bien que mettre une sémantique dans le nom de fichier (l'extension, en l'occurrence) soit une hérésie (un nom est... un nom), le système retenu par Apple est sûrement le meilleur compromis. Il reste que l'UI devrait toujours informer l'utilisateur si un fichier a une double extension. En plus, les launch-services sont à même de déceler ce genre de "manipulation" (c'est même utilisé par le Finder quand tu changes l'extension d'un fichier...)
Pour finir, le communiqué d'Intego semble mentionner que c'est dans un tag ID3 que le truc se loge... ça m'étonne un peu. Donc soit c'est n'importe quoi, soit c'est juste un bug de iTunes.
-- Julien Jalon <http://www.julien-jalon.org/> Ce que contient ce message n'exprime que mon opinion et non celle de mon employeur.
Éric Lévénez <news@levenez.com> wrote:
C'est pas vraiment nouveau comme truc. Avec Mac OS X et sa gestion des
extensions cachées, des type/créateurs cachés, des icônes modifiables, toute
icône montrant un type de fichier peut être en fait un tout autre type de
fichier. Si Apple abandonnait les types/créateurs, les extensions cachés et
la modification des icônes des fichiers, on aurait un système plus sûr :
l'icône d'un document d'une application lancerait cette application.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Arf, tu recommences à dire n'importe quoi, mon cher ami...
L'extension est toujours visible dans une appli de mail (le fait que
l'extension soit cachée étant une propriété propre à un fichier stocké
sur un file-system HFS. En gros, pour réaliser une telle chose, il faut
encapsuler le pseudo fichier .mp3.app (par exemple) dans une image DMG
(ça marche aussi pour une archive non "HFS compliant" mais il faut
rajouter des fichiers additionels pour simuler cette propriété, regarder
par exemple les archives ZIP produites par le Finder avec unzip -l dans
un terminal)
Bien que mettre une sémantique dans le nom de fichier (l'extension, en
l'occurrence) soit une hérésie (un nom est... un nom), le système retenu
par Apple est sûrement le meilleur compromis. Il reste que l'UI devrait
toujours informer l'utilisateur si un fichier a une double extension.
En plus, les launch-services sont à même de déceler ce genre de
"manipulation" (c'est même utilisé par le Finder quand tu changes
l'extension d'un fichier...)
Pour finir, le communiqué d'Intego semble mentionner que c'est dans un
tag ID3 que le truc se loge... ça m'étonne un peu. Donc soit c'est
n'importe quoi, soit c'est juste un bug de iTunes.
--
Julien Jalon <http://www.julien-jalon.org/>
Ce que contient ce message n'exprime que mon opinion et non celle de
mon employeur.
C'est pas vraiment nouveau comme truc. Avec Mac OS X et sa gestion des extensions cachées, des type/créateurs cachés, des icônes modifiables, toute icône montrant un type de fichier peut être en fait un tout autre type de fichier. Si Apple abandonnait les types/créateurs, les extensions cachés et la modification des icônes des fichiers, on aurait un système plus sûr : l'icône d'un document d'une application lancerait cette application.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Arf, tu recommences à dire n'importe quoi, mon cher ami... L'extension est toujours visible dans une appli de mail (le fait que l'extension soit cachée étant une propriété propre à un fichier stocké sur un file-system HFS. En gros, pour réaliser une telle chose, il faut encapsuler le pseudo fichier .mp3.app (par exemple) dans une image DMG (ça marche aussi pour une archive non "HFS compliant" mais il faut rajouter des fichiers additionels pour simuler cette propriété, regarder par exemple les archives ZIP produites par le Finder avec unzip -l dans un terminal)
Bien que mettre une sémantique dans le nom de fichier (l'extension, en l'occurrence) soit une hérésie (un nom est... un nom), le système retenu par Apple est sûrement le meilleur compromis. Il reste que l'UI devrait toujours informer l'utilisateur si un fichier a une double extension. En plus, les launch-services sont à même de déceler ce genre de "manipulation" (c'est même utilisé par le Finder quand tu changes l'extension d'un fichier...)
Pour finir, le communiqué d'Intego semble mentionner que c'est dans un tag ID3 que le truc se loge... ça m'étonne un peu. Donc soit c'est n'importe quoi, soit c'est juste un bug de iTunes.
-- Julien Jalon <http://www.julien-jalon.org/> Ce que contient ce message n'exprime que mon opinion et non celle de mon employeur.
jalon
Bon, donc, après vérification, c'est bien un problème des meta-data... le système de cachage d'extension de MacOS X n'est pas en cause.
-- Julien Jalon <http://www.julien-jalon.org/> Ce que contient ce message n'exprime que mon opinion et non celle de mon employeur.
Bon, donc, après vérification, c'est bien un problème des meta-data...
le système de cachage d'extension de MacOS X n'est pas en cause.
--
Julien Jalon <http://www.julien-jalon.org/>
Ce que contient ce message n'exprime que mon opinion et non celle de
mon employeur.
Bon, donc, après vérification, c'est bien un problème des meta-data... le système de cachage d'extension de MacOS X n'est pas en cause.
-- Julien Jalon <http://www.julien-jalon.org/> Ce que contient ce message n'exprime que mon opinion et non celle de mon employeur.
patpro ~ patrick proniewski
In article , (Julien Jalon) wrote:
Arf, tu recommences à dire n'importe quoi, mon cher ami... L'extension est toujours visible dans une appli de mail [snip]
et les appli carbon n'ont pas de .app, et si tu colles .mp3 derriere l'utilisateur n'y voit que du feu.
Pour finir, le communiqué d'Intego semble mentionner que c'est dans un tag ID3 que le truc se loge... ça m'étonne un peu. Donc soit c'est n'importe quoi, soit c'est juste un bug de iTunes.
c'est pas n'importe quoi, ca a été discuté ici dans une enfilade de plus de 65 messages, pas plus tard que cette semaine. Il s'agit juste d'une appli carbon nommée truc.mp3, contenant en data un vrai mp3 et dont le code viral est dans un tag ID3. L'amorce du fichier fait en sorte que le code contenu dans le tag ID3 soit executé. Le code en question, si il est malin, lance itunes et force ce dernier a lire truc.mp3 comme un fichier audio. Le tour est joué.
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
In article <f1l45c.ofp.ln@joshua.julien-jalon.org>,
jalon@julien-jalon.org (Julien Jalon) wrote:
Arf, tu recommences à dire n'importe quoi, mon cher ami...
L'extension est toujours visible dans une appli de mail
[snip]
et les appli carbon n'ont pas de .app, et si tu colles .mp3 derriere
l'utilisateur n'y voit que du feu.
Pour finir, le communiqué d'Intego semble mentionner que c'est dans un
tag ID3 que le truc se loge... ça m'étonne un peu. Donc soit c'est
n'importe quoi, soit c'est juste un bug de iTunes.
c'est pas n'importe quoi, ca a été discuté ici dans une enfilade de plus
de 65 messages, pas plus tard que cette semaine.
Il s'agit juste d'une appli carbon nommée truc.mp3, contenant en data un
vrai mp3 et dont le code viral est dans un tag ID3. L'amorce du fichier
fait en sorte que le code contenu dans le tag ID3 soit executé. Le code
en question, si il est malin, lance itunes et force ce dernier a lire
truc.mp3 comme un fichier audio. Le tour est joué.
patpro
--
je cherche un poste d'admin UNIX/Mac
http://patpro.net/cv.php
Arf, tu recommences à dire n'importe quoi, mon cher ami... L'extension est toujours visible dans une appli de mail [snip]
et les appli carbon n'ont pas de .app, et si tu colles .mp3 derriere l'utilisateur n'y voit que du feu.
Pour finir, le communiqué d'Intego semble mentionner que c'est dans un tag ID3 que le truc se loge... ça m'étonne un peu. Donc soit c'est n'importe quoi, soit c'est juste un bug de iTunes.
c'est pas n'importe quoi, ca a été discuté ici dans une enfilade de plus de 65 messages, pas plus tard que cette semaine. Il s'agit juste d'une appli carbon nommée truc.mp3, contenant en data un vrai mp3 et dont le code viral est dans un tag ID3. L'amorce du fichier fait en sorte que le code contenu dans le tag ID3 soit executé. Le code en question, si il est malin, lance itunes et force ce dernier a lire truc.mp3 comme un fichier audio. Le tour est joué.
patpro
-- je cherche un poste d'admin UNIX/Mac http://patpro.net/cv.php
Patrick Stadelmann
In article , (Julien Jalon) wrote:
L'extension est toujours visible dans une appli de mail
Sauf que le .app n'est pas du tout nécessaire. La "proof of concept" ci-dessous s'appelle bien "virus.mp3"
Bien que mettre une sémantique dans le nom de fichier (l'extension, en l'occurrence) soit une hérésie (un nom est... un nom), le système retenu par Apple est sûrement le meilleur compromis. Il reste que l'UI devrait toujours informer l'utilisateur si un fichier a une double extension.
Pour le coup du .app c'est en partie le cas, voir :
Pour finir, le communiqué d'Intego semble mentionner que c'est dans un tag ID3 que le truc se loge... ça m'étonne un peu. Donc soit c'est n'importe quoi, soit c'est juste un bug de iTunes.
Le virus est probablement dérivé de :
Le code se trouve bien dans un tag MP3. La ressource 'cfrg' indique simplement au système que l'appli ne commence pas à l'offset 0 du data fork (vu que là il y a un header MP3 valide) mais un peu plus loin.
On peut dire tout ce que l'on veut, être impressioné par le fait que cette appli est lue sans problème par iTunes comme un fichier MP3, il n'en reste pas moins que ce fichier est vu comme une application par le Finder, et que donc la supercherie est détecable si on prend un minimum de précaution : vérifier le type d'un fichier de manière plus fiable qu'en se basant sur son icône (champ "Type" dans le Finder par exemple) si l'on n'est pas certain de son origine.
Patrick -- Patrick Stadelmann
In article <f1l45c.ofp.ln@joshua.julien-jalon.org>,
jalon@julien-jalon.org (Julien Jalon) wrote:
L'extension est toujours visible dans une appli de mail
Sauf que le .app n'est pas du tout nécessaire. La "proof of concept"
ci-dessous s'appelle bien "virus.mp3"
Bien que mettre une sémantique dans le nom de fichier (l'extension, en
l'occurrence) soit une hérésie (un nom est... un nom), le système retenu
par Apple est sûrement le meilleur compromis. Il reste que l'UI devrait
toujours informer l'utilisateur si un fichier a une double extension.
Pour le coup du .app c'est en partie le cas, voir :
<Patrick.Stadelmann-CF3F20.14085507042004@news.fu-berlin.de>
Pour finir, le communiqué d'Intego semble mentionner que c'est dans un
tag ID3 que le truc se loge... ça m'étonne un peu. Donc soit c'est
n'importe quoi, soit c'est juste un bug de iTunes.
Le virus est probablement dérivé de :
<blgl-5D750C.02150821032004@news.bahnhof.se>
Le code se trouve bien dans un tag MP3. La ressource 'cfrg' indique
simplement au système que l'appli ne commence pas à l'offset 0 du data
fork (vu que là il y a un header MP3 valide) mais un peu plus loin.
On peut dire tout ce que l'on veut, être impressioné par le fait que
cette appli est lue sans problème par iTunes comme un fichier MP3, il
n'en reste pas moins que ce fichier est vu comme une application par le
Finder, et que donc la supercherie est détecable si on prend un minimum
de précaution : vérifier le type d'un fichier de manière plus fiable
qu'en se basant sur son icône (champ "Type" dans le Finder par exemple)
si l'on n'est pas certain de son origine.
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
L'extension est toujours visible dans une appli de mail
Sauf que le .app n'est pas du tout nécessaire. La "proof of concept" ci-dessous s'appelle bien "virus.mp3"
Bien que mettre une sémantique dans le nom de fichier (l'extension, en l'occurrence) soit une hérésie (un nom est... un nom), le système retenu par Apple est sûrement le meilleur compromis. Il reste que l'UI devrait toujours informer l'utilisateur si un fichier a une double extension.
Pour le coup du .app c'est en partie le cas, voir :
Pour finir, le communiqué d'Intego semble mentionner que c'est dans un tag ID3 que le truc se loge... ça m'étonne un peu. Donc soit c'est n'importe quoi, soit c'est juste un bug de iTunes.
Le virus est probablement dérivé de :
Le code se trouve bien dans un tag MP3. La ressource 'cfrg' indique simplement au système que l'appli ne commence pas à l'offset 0 du data fork (vu que là il y a un header MP3 valide) mais un peu plus loin.
On peut dire tout ce que l'on veut, être impressioné par le fait que cette appli est lue sans problème par iTunes comme un fichier MP3, il n'en reste pas moins que ce fichier est vu comme une application par le Finder, et que donc la supercherie est détecable si on prend un minimum de précaution : vérifier le type d'un fichier de manière plus fiable qu'en se basant sur son icône (champ "Type" dans le Finder par exemple) si l'on n'est pas certain de son origine.
