depuis environ 1h30 mon serveur de messagerie reçoit des mails arrivants
avec des pièces jointes au format pif (my_details.pif, document.pif,
your_document.pif ...).
Le firewall avec sa base antivirale à jour laisse passer, l'antivirus à
jour du serveur de messagerie ne dit rien (norton for exchange), ce
n'est que parce que j'ai interdit toute pièce jointe de type executable
(exe, com, pif et compagnie) que les fichiers sont détruit.
Et les characteres NULLs au millieu du nom du fichier, et les characteres nulls dans le corps du message juste avant les balises MIME, et les filenames du genre :
filename=toto titi.exe
ou encore
filename=dkdk[1].scr
Il y avait une vielle adresse (trop vieille deja) avec une liste de pieges... Peut-etre que Roland se rappelle... C'etait dans un pays de l'est.
Jose-Marcio
-- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:
Bonjour,
Laurent Wacrenier wrote:
Roland Garcia <roland-garcia@wanadoo.fr> écrit:
La suppression de pièces jointes suffixées de telle ou telle manière
n'est pas une solution universellement acceptable
Pour les suffixes exécutables si.
Pas universellement.
Si, il faut être fou pour accepter le premier exécutable venu, plus
aucune sécurité n'est possible.
Tu confonds "acceptable" et "préférable".
C'est à dire qu'il respecte la RFC 2047 ?
C'est vieux tout ça:
http://www.google.fr/groups?ie=UTF-8&oe=UTF-8&as_umsgid=90A5F9.8020802%40wanadoo.fr&lr=&hl=fr
Ça ne parle pas de la RFC 2047. Est t'il capable de voir le .exe dans
une entête comme celle ci dessous ?
Et les characteres NULLs au millieu du nom du fichier, et les
characteres nulls dans le corps du message juste avant les balises MIME,
et les filenames du genre :
filename=toto titi.exe
ou encore
filename=dkdk[1].scr
Il y avait une vielle adresse (trop vieille deja) avec une liste de
pieges... Peut-etre que Roland se rappelle... C'etait dans un pays de l'est.
Jose-Marcio
--
---------------------------------------------------------------
Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41
Ecole des Mines de Paris http://j-chkmail.ensmp.fr
60, bd Saint Michel http://www.ensmp.fr/~martins
75272 - PARIS CEDEX 06 mailto:Jose-Marcio.Martins@ensmp.fr
Et les characteres NULLs au millieu du nom du fichier, et les characteres nulls dans le corps du message juste avant les balises MIME, et les filenames du genre :
filename=toto titi.exe
ou encore
filename=dkdk[1].scr
Il y avait une vielle adresse (trop vieille deja) avec une liste de pieges... Peut-etre que Roland se rappelle... C'etait dans un pays de l'est.
Jose-Marcio
-- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:
Laurent Wacrenier
Jose Marcio Martins da Cruz écrit:
Et je ne parle même pas des mauvais encodages.
Exemples de mauvais codages vus à droite à gauche : - =?windows-1256?b?ZQ?= à la place de =?windows-1256?b?ZQ==? - mauvais encodage UTF-8 (forme non canonique) - jeux de caractère x-user-defined - blancs à l'interieur du codage (=?windows-1256?b?Z Q = =?=) - caractère hors du jeux de caractères (un "è" dans de l'US-ASCII) - encodage RFC2047 mal terminé (=?utf-8?b?ZVg=?)
Bien qu'avec tout celà mélangé, le client ne doit pas comprendre grand chose.
Sinon d'autres curiosités : fichiers uuencodés, fichiers uuencodés avec des entités HTML.
Jose Marcio Martins da Cruz <Jose-Marcio.Martins@ensmp.fr> écrit:
Et je ne parle même pas des mauvais encodages.
Exemples de mauvais codages vus à droite à gauche :
- =?windows-1256?b?ZQ?= à la place de =?windows-1256?b?ZQ==? - mauvais encodage UTF-8 (forme non canonique)
- jeux de caractère x-user-defined
- blancs à l'interieur du codage (=?windows-1256?b?Z Q = =?=)
- caractère hors du jeux de caractères (un "è" dans de l'US-ASCII)
- encodage RFC2047 mal terminé (=?utf-8?b?ZVg=?)
Bien qu'avec tout celà mélangé, le client ne doit pas comprendre grand
chose.
Sinon d'autres curiosités : fichiers uuencodés, fichiers uuencodés
avec des entités HTML.
Exemples de mauvais codages vus à droite à gauche : - =?windows-1256?b?ZQ?= à la place de =?windows-1256?b?ZQ==? - mauvais encodage UTF-8 (forme non canonique) - jeux de caractère x-user-defined - blancs à l'interieur du codage (=?windows-1256?b?Z Q = =?=) - caractère hors du jeux de caractères (un "è" dans de l'US-ASCII) - encodage RFC2047 mal terminé (=?utf-8?b?ZVg=?)
Bien qu'avec tout celà mélangé, le client ne doit pas comprendre grand chose.
Sinon d'autres curiosités : fichiers uuencodés, fichiers uuencodés avec des entités HTML.
Jose Marcio Martins da Cruz
Laurent Wacrenier wrote:
Jose Marcio Martins da Cruz écrit:
Et je ne parle même pas des mauvais encodages.
Exemples de mauvais codages vus à droite à gauche : - =?windows-1256?b?ZQ?= à la place de =?windows-1256?b?ZQ==? > - mauvais encodage UTF-8 (forme non canonique) - jeux de caractère x-user-defined - blancs à l'interieur du codage (=?windows-1256?b?Z Q = =?=) - caractère hors du jeux de caractères (un "è" dans de l'US-ASCII) - encodage RFC2047 mal terminé (=?utf-8?b?ZVg=?)
Bien qu'avec tout celà mélangé, le client ne doit pas comprendre grand chose.
J'ai prevu plusieurs trucs, mais pas tous.
Parmi ceux que j'ai prevu, il y en avait qui je n'ai pas implemente. La decision etait prise sur la reaction d'une malformation sur un client Outlock. Si le client Outlock decode la malformation comme etant un fichier executable, alors la, ca vaut le coup de le traiter.
Sinon, il arrive un moment ou si on accepte toute malformation, on va introduire des erreurs dans des cas qui sont tout a fait normaux - des faux positifs.
Sinon d'autres curiosités : fichiers uuencodés, fichiers uuencodés avec des entités HTML.
Oui.
Mais on ne detecte pas, par exemple, certains virus du genre KaK qui contiennent des scripts dans du html, sans fichier attache. Dans ce cas, c'est l'antispam qui s'en occupe - identification de fausses balises HTML et balises non souhaitees (script, img, http://.*http://.*, ...)
-- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:
Laurent Wacrenier wrote:
Jose Marcio Martins da Cruz <Jose-Marcio.Martins@ensmp.fr> écrit:
Et je ne parle même pas des mauvais encodages.
Exemples de mauvais codages vus à droite à gauche :
- =?windows-1256?b?ZQ?= à la place de =?windows-1256?b?ZQ==? > - mauvais encodage UTF-8 (forme non canonique)
- jeux de caractère x-user-defined
- blancs à l'interieur du codage (=?windows-1256?b?Z Q = =?=)
- caractère hors du jeux de caractères (un "è" dans de l'US-ASCII)
- encodage RFC2047 mal terminé (=?utf-8?b?ZVg=?)
Bien qu'avec tout celà mélangé, le client ne doit pas comprendre grand
chose.
J'ai prevu plusieurs trucs, mais pas tous.
Parmi ceux que j'ai prevu, il y en avait qui je n'ai pas implemente. La
decision etait prise sur la reaction d'une malformation sur un client
Outlock. Si le client Outlock decode la malformation comme etant un
fichier executable, alors la, ca vaut le coup de le traiter.
Sinon, il arrive un moment ou si on accepte toute malformation, on va
introduire des erreurs dans des cas qui sont tout a fait normaux - des
faux positifs.
Sinon d'autres curiosités : fichiers uuencodés, fichiers uuencodés
avec des entités HTML.
Oui.
Mais on ne detecte pas, par exemple, certains virus du genre KaK qui
contiennent des scripts dans du html, sans fichier attache. Dans ce cas,
c'est l'antispam qui s'en occupe - identification de fausses balises
HTML et balises non souhaitees (script, img, http://.*http://.*, ...)
--
---------------------------------------------------------------
Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41
Ecole des Mines de Paris http://j-chkmail.ensmp.fr
60, bd Saint Michel http://www.ensmp.fr/~martins
75272 - PARIS CEDEX 06 mailto:Jose-Marcio.Martins@ensmp.fr
Exemples de mauvais codages vus à droite à gauche : - =?windows-1256?b?ZQ?= à la place de =?windows-1256?b?ZQ==? > - mauvais encodage UTF-8 (forme non canonique) - jeux de caractère x-user-defined - blancs à l'interieur du codage (=?windows-1256?b?Z Q = =?=) - caractère hors du jeux de caractères (un "è" dans de l'US-ASCII) - encodage RFC2047 mal terminé (=?utf-8?b?ZVg=?)
Bien qu'avec tout celà mélangé, le client ne doit pas comprendre grand chose.
J'ai prevu plusieurs trucs, mais pas tous.
Parmi ceux que j'ai prevu, il y en avait qui je n'ai pas implemente. La decision etait prise sur la reaction d'une malformation sur un client Outlock. Si le client Outlock decode la malformation comme etant un fichier executable, alors la, ca vaut le coup de le traiter.
Sinon, il arrive un moment ou si on accepte toute malformation, on va introduire des erreurs dans des cas qui sont tout a fait normaux - des faux positifs.
Sinon d'autres curiosités : fichiers uuencodés, fichiers uuencodés avec des entités HTML.
Oui.
Mais on ne detecte pas, par exemple, certains virus du genre KaK qui contiennent des scripts dans du html, sans fichier attache. Dans ce cas, c'est l'antispam qui s'en occupe - identification de fausses balises HTML et balises non souhaitees (script, img, http://.*http://.*, ...)
-- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:
Roland Garcia
Il y avait une vielle adresse (trop vieille deja) avec une liste de pieges... Peut-etre que Roland se rappelle...
Oui mais je ne sais plus où.....
C'etait dans un pays de l'est.
Ca va de soi :-)
Roland Garcia
Il y avait une vielle adresse (trop vieille deja) avec une liste de
pieges... Peut-etre que Roland se rappelle...
Il y avait une vielle adresse (trop vieille deja) avec une liste de pieges... Peut-etre que Roland se rappelle...
Oui mais je ne sais plus où.....
C'etait dans un pays de l'est.
Ca va de soi :-)
Roland Garcia
-- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:
Hello,
Il y avait encore une vieille et bonne apparue avec Klez (ceci est un
cas reel) :
Il y avait une vielle adresse (trop vieille deja) avec une liste de
pieges... Peut-etre que Roland se rappelle...
Oui mais je ne sais plus où.....
C'etait dans un pays de l'est.
Ca va de soi :-)
Roland Garcia
--
---------------------------------------------------------------
Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41
Ecole des Mines de Paris http://j-chkmail.ensmp.fr
60, bd Saint Michel http://www.ensmp.fr/~martins
75272 - PARIS CEDEX 06 mailto:Jose-Marcio.Martins@ensmp.fr
Il y avait une vielle adresse (trop vieille deja) avec une liste de pieges... Peut-etre que Roland se rappelle...
Oui mais je ne sais plus où.....
C'etait dans un pays de l'est.
Ca va de soi :-)
Roland Garcia
-- --------------------------------------------------------------- Jose Marcio MARTINS DA CRUZ Tel. :(33) 01.40.51.93.41 Ecole des Mines de Paris http://j-chkmail.ensmp.fr 60, bd Saint Michel http://www.ensmp.fr/~martins 75272 - PARIS CEDEX 06 mailto:
Laurent Wacrenier
Jose Marcio Martins da Cruz écrit:
Mais on ne detecte pas, par exemple, certains virus du genre KaK qui contiennent des scripts dans du html, sans fichier attache. Dans ce cas, c'est l'antispam qui s'en occupe - identification de fausses balises HTML et balises non souhaitees (script, img, http://.*http://.*, ...)
Ça doit être aussi possible de détecter le type du fichier sur son amorce (comme la commande "file" sous Unix) plutôt que sur son nom.
Jose Marcio Martins da Cruz <Jose-Marcio.Martins@ensmp.fr> écrit:
Mais on ne detecte pas, par exemple, certains virus du genre KaK qui
contiennent des scripts dans du html, sans fichier attache. Dans ce cas,
c'est l'antispam qui s'en occupe - identification de fausses balises
HTML et balises non souhaitees (script, img, http://.*http://.*, ...)
Ça doit être aussi possible de détecter le type du fichier sur son
amorce (comme la commande "file" sous Unix) plutôt que sur son nom.
Mais on ne detecte pas, par exemple, certains virus du genre KaK qui contiennent des scripts dans du html, sans fichier attache. Dans ce cas, c'est l'antispam qui s'en occupe - identification de fausses balises HTML et balises non souhaitees (script, img, http://.*http://.*, ...)
Ça doit être aussi possible de détecter le type du fichier sur son amorce (comme la commande "file" sous Unix) plutôt que sur son nom.
Olivier Aichelbaum
Laurent Wacrenier wrote:
Roland Garcia écrit:
La suppression de pièces jointes suffixées de telle ou telle manière n'est pas une solution universellement acceptable
Pour les suffixes exécutables si.
Pas universellement. Dans un système privé (une entreprise, une école, chez soi, etc.), c'est lié à la politique de sécurité du système décidée de manière centrale en fonction d'objectifs précis. Dans un système public (un FAI, etc.), il n'y a pas de telles choses.
En effet, tout dépend de la politique de sécurité. Il semblerait que certains en face aient changé de position car il n'y a pas si longtemps ils se moquaient de Jaja (je crois) qui expliquait qu'il supprimait tous les EXE attachés... Le vent peut être... ;)
-- Olivier Aichelbaum
Laurent Wacrenier wrote:
Roland Garcia <roland-garcia@wanadoo.fr> écrit:
La suppression de pièces jointes suffixées de telle ou telle manière
n'est pas une solution universellement acceptable
Pour les suffixes exécutables si.
Pas universellement. Dans un système privé (une entreprise, une école,
chez soi, etc.), c'est lié à la politique de sécurité du système
décidée de manière centrale en fonction d'objectifs précis. Dans un
système public (un FAI, etc.), il n'y a pas de telles choses.
En effet, tout dépend de la politique de sécurité. Il semblerait
que certains en face aient changé de position car il n'y a pas si
longtemps ils se moquaient de Jaja (je crois) qui expliquait qu'il
supprimait tous les EXE attachés... Le vent peut être... ;)
La suppression de pièces jointes suffixées de telle ou telle manière n'est pas une solution universellement acceptable
Pour les suffixes exécutables si.
Pas universellement. Dans un système privé (une entreprise, une école, chez soi, etc.), c'est lié à la politique de sécurité du système décidée de manière centrale en fonction d'objectifs précis. Dans un système public (un FAI, etc.), il n'y a pas de telles choses.
En effet, tout dépend de la politique de sécurité. Il semblerait que certains en face aient changé de position car il n'y a pas si longtemps ils se moquaient de Jaja (je crois) qui expliquait qu'il supprimait tous les EXE attachés... Le vent peut être... ;)
-- Olivier Aichelbaum
Frederic Bonroy
Olivier Aichelbaum wrote:
En effet, tout dépend de la politique de sécurité. Il semblerait que certains en face aient changé de position car il n'y a pas si longtemps ils se moquaient de Jaja (je crois) qui expliquait qu'il supprimait tous les EXE attachés... Le vent peut être... ;)
On se moquait surtout de l'affirmation selon laquelle tous les .exe attachés à des messages sont forcément des virus.
Olivier Aichelbaum wrote:
En effet, tout dépend de la politique de sécurité. Il semblerait
que certains en face aient changé de position car il n'y a pas si
longtemps ils se moquaient de Jaja (je crois) qui expliquait qu'il
supprimait tous les EXE attachés... Le vent peut être... ;)
On se moquait surtout de l'affirmation selon laquelle tous les .exe
attachés à des messages sont forcément des virus.
En effet, tout dépend de la politique de sécurité. Il semblerait que certains en face aient changé de position car il n'y a pas si longtemps ils se moquaient de Jaja (je crois) qui expliquait qu'il supprimait tous les EXE attachés... Le vent peut être... ;)
On se moquait surtout de l'affirmation selon laquelle tous les .exe attachés à des messages sont forcément des virus.
Olivier Aichelbaum
Frederic Bonroy wrote:
Olivier Aichelbaum wrote:
En effet, tout dépend de la politique de sécurité. Il semblerait que certains en face aient changé de position car il n'y a pas si longtemps ils se moquaient de Jaja (je crois) qui expliquait qu'il supprimait tous les EXE attachés... Le vent peut être... ;)
On se moquait surtout de l'affirmation selon laquelle tous les .exe attachés à des messages sont forcément des virus.
Ca dépend de sa politique de sécurité avec ses contacts.
-- Olivier Aichelbaum
Frederic Bonroy wrote:
Olivier Aichelbaum wrote:
En effet, tout dépend de la politique de sécurité. Il semblerait
que certains en face aient changé de position car il n'y a pas si
longtemps ils se moquaient de Jaja (je crois) qui expliquait qu'il
supprimait tous les EXE attachés... Le vent peut être... ;)
On se moquait surtout de l'affirmation selon laquelle tous les .exe
attachés à des messages sont forcément des virus.
Ca dépend de sa politique de sécurité avec ses contacts.
En effet, tout dépend de la politique de sécurité. Il semblerait que certains en face aient changé de position car il n'y a pas si longtemps ils se moquaient de Jaja (je crois) qui expliquait qu'il supprimait tous les EXE attachés... Le vent peut être... ;)
On se moquait surtout de l'affirmation selon laquelle tous les .exe attachés à des messages sont forcément des virus.
Ca dépend de sa politique de sécurité avec ses contacts.
