Quand on sait que pour qu'un logiciel de quelques milliers de lignes soit reconnut comme fiable et maintenable, il faut faire plancher des ingénieurs spécialisés pendant des mois...
Heu.. non, à moins que ce soient des ingénieurs spécialisés dans autre chose que le développement.
Heu, si.
ça laisse à réfléchir pour un joujou comme Windows.
Je ne suis pas sûr qu'il ai été conçu par des informaticiens.
Ben non voyons, par des ânes...
Mine de rien, les intéractions logiciel-matériel sont très complexes pour un système d'exploitation. Il est même illusoire de penser qu'un OS puisse être infaillible.
Il n'y a pas de fatalité.
Ha, et tes solutions ? Tu programmes un peu ? Tiens voici un petit exemple de la difficulté de coder 100% sûr. Suppose que tu aies à implémenter une routine de transaction simple via un réseau. Allez, dison le Net. Le codeur doit faire gaffe :
- Aux buffers overflows, - Aux stack overflows, - Aux string overflows, - Aux integer overflows.
Chacun de ces problèmes est différent à prendre en compte et à traiter. Pourtant, très faciles à générer en quelque lignes de code transactionnel. Et pas franchement très évident à éviter ou contrecarrer.
- Aux injections de code, - Aux déni de services dus à de flux externes, - Au déroutement de privilège (autorisation de debug ?),
Là ça ne rit plus, si tu dois tenir compte de tout ça et tester et éprouver, prépare de longues heures...
- Aux déroutements via des services, - Aux race conditions, - Aux déroutement via patch de l'IAT,
Encore un cran plus bas...
Je dois m'absenter quelques heures là, je ne peux donc continuer une liste qui pourrait être très très longue. Tu peux trouver des dizainesde méthodes plus ou moins alambiquées pour pervertir un code. Certaines qui dépasseront et de loin les compétences du programmeur moyen qui n'a pas suivi de formation à leur sujet. Ni son chef de projet d'ailleurs. N'oublie pas le temps imparti à chaque tâche, toujours très limité. par exemple, pour coder la routine que je prends en exemple, t'auras guère plus de 3-4 heures à ta disposition. N'oublie pas non plus que tu ne peux pas contrôler l'environnement d'exécution de ton code : quid de l'environenment du client ? sécurité mise en place, etc.
Pas de fatalité ? Tant que les facteurs de décision seront basés sur la rentabilité, j'en doute...
-- AMcD
http://arnold.mcdonald.free.fr/
Laurent Wacrenier wrote:
Misterjack <stock@mjcie.info> écrit:
Quand on sait que pour qu'un logiciel de quelques milliers de lignes
soit reconnut comme fiable et maintenable, il faut faire plancher des
ingénieurs spécialisés pendant des mois...
Heu.. non, à moins que ce soient des ingénieurs spécialisés dans autre
chose que le développement.
Heu, si.
ça laisse à réfléchir pour un joujou comme Windows.
Je ne suis pas sûr qu'il ai été conçu par des informaticiens.
Ben non voyons, par des ânes...
Mine de rien, les intéractions logiciel-matériel sont très complexes
pour un système d'exploitation. Il est même illusoire de penser
qu'un OS puisse être infaillible.
Il n'y a pas de fatalité.
Ha, et tes solutions ? Tu programmes un peu ? Tiens voici un petit exemple
de la difficulté de coder 100% sûr. Suppose que tu aies à implémenter une
routine de transaction simple via un réseau. Allez, dison le Net. Le codeur
doit faire gaffe :
- Aux buffers overflows,
- Aux stack overflows,
- Aux string overflows,
- Aux integer overflows.
Chacun de ces problèmes est différent à prendre en compte et à traiter.
Pourtant, très faciles à générer en quelque lignes de code transactionnel.
Et pas franchement très évident à éviter ou contrecarrer.
- Aux injections de code,
- Aux déni de services dus à de flux externes,
- Au déroutement de privilège (autorisation de debug ?),
Là ça ne rit plus, si tu dois tenir compte de tout ça et tester et éprouver,
prépare de longues heures...
- Aux déroutements via des services,
- Aux race conditions,
- Aux déroutement via patch de l'IAT,
Encore un cran plus bas...
Je dois m'absenter quelques heures là, je ne peux donc continuer une liste
qui pourrait être très très longue. Tu peux trouver des dizainesde méthodes
plus ou moins alambiquées pour pervertir un code. Certaines qui dépasseront
et de loin les compétences du programmeur moyen qui n'a pas suivi de
formation à leur sujet. Ni son chef de projet d'ailleurs. N'oublie pas le
temps imparti à chaque tâche, toujours très limité. par exemple, pour coder
la routine que je prends en exemple, t'auras guère plus de 3-4 heures à ta
disposition. N'oublie pas non plus que tu ne peux pas contrôler
l'environnement d'exécution de ton code : quid de l'environenment du client
? sécurité mise en place, etc.
Pas de fatalité ? Tant que les facteurs de décision seront basés sur la
rentabilité, j'en doute...
Quand on sait que pour qu'un logiciel de quelques milliers de lignes soit reconnut comme fiable et maintenable, il faut faire plancher des ingénieurs spécialisés pendant des mois...
Heu.. non, à moins que ce soient des ingénieurs spécialisés dans autre chose que le développement.
Heu, si.
ça laisse à réfléchir pour un joujou comme Windows.
Je ne suis pas sûr qu'il ai été conçu par des informaticiens.
Ben non voyons, par des ânes...
Mine de rien, les intéractions logiciel-matériel sont très complexes pour un système d'exploitation. Il est même illusoire de penser qu'un OS puisse être infaillible.
Il n'y a pas de fatalité.
Ha, et tes solutions ? Tu programmes un peu ? Tiens voici un petit exemple de la difficulté de coder 100% sûr. Suppose que tu aies à implémenter une routine de transaction simple via un réseau. Allez, dison le Net. Le codeur doit faire gaffe :
- Aux buffers overflows, - Aux stack overflows, - Aux string overflows, - Aux integer overflows.
Chacun de ces problèmes est différent à prendre en compte et à traiter. Pourtant, très faciles à générer en quelque lignes de code transactionnel. Et pas franchement très évident à éviter ou contrecarrer.
- Aux injections de code, - Aux déni de services dus à de flux externes, - Au déroutement de privilège (autorisation de debug ?),
Là ça ne rit plus, si tu dois tenir compte de tout ça et tester et éprouver, prépare de longues heures...
- Aux déroutements via des services, - Aux race conditions, - Aux déroutement via patch de l'IAT,
Encore un cran plus bas...
Je dois m'absenter quelques heures là, je ne peux donc continuer une liste qui pourrait être très très longue. Tu peux trouver des dizainesde méthodes plus ou moins alambiquées pour pervertir un code. Certaines qui dépasseront et de loin les compétences du programmeur moyen qui n'a pas suivi de formation à leur sujet. Ni son chef de projet d'ailleurs. N'oublie pas le temps imparti à chaque tâche, toujours très limité. par exemple, pour coder la routine que je prends en exemple, t'auras guère plus de 3-4 heures à ta disposition. N'oublie pas non plus que tu ne peux pas contrôler l'environnement d'exécution de ton code : quid de l'environenment du client ? sécurité mise en place, etc.
Pas de fatalité ? Tant que les facteurs de décision seront basés sur la rentabilité, j'en doute...
-- AMcD
http://arnold.mcdonald.free.fr/
ppc
AMcD wrote: Le codeur
doit faire gaffe :
- Aux buffers overflows, - Aux stack overflows, - Aux string overflows, - Aux integer overflows.
Pour un défendeur de la langue française pure qui déteste l'anglomanie ?
AMcD wrote:
Le codeur
doit faire gaffe :
- Aux buffers overflows,
- Aux stack overflows,
- Aux string overflows,
- Aux integer overflows.
Pour un défendeur de la langue française pure qui
déteste l'anglomanie ?
- Aux buffers overflows, - Aux stack overflows, - Aux string overflows, - Aux integer overflows.
Pour un défendeur de la langue française pure qui déteste l'anglomanie ?
Nicob
On Wed, 05 Nov 2003 20:13:22 +0100, AMcD wrote:
[...] faire des sites potables avec Opera [...]
Mouais ... Là encore, le quasi-monopole d'IE entre en compte.
D'un côté, il est vrai que Opera a longtemps manqué de fonctionnalités exotiques (certains plugins, le DHTML, ...). D'un autre côté, il m'est arrivé de remonter aux développeurs d'Opera des bugs (fonctionnel et/ou sécurité) qui étaient rejetés pour cause de besoin d'émuler au mieux le fonctionnement d'IE et d'éviter ainsi les utilisateurs remontant ce qui leur semble être un bug ("ça marche sous IE mais pas sous Opera") alors que c'est le comportement W3C-compliant ou "naturel" ...
Nicob
On Wed, 05 Nov 2003 20:13:22 +0100, AMcD wrote:
[...] faire des sites potables avec Opera [...]
Mouais ...
Là encore, le quasi-monopole d'IE entre en compte.
D'un côté, il est vrai que Opera a longtemps manqué de fonctionnalités
exotiques (certains plugins, le DHTML, ...). D'un autre côté, il
m'est arrivé de remonter aux développeurs d'Opera des bugs (fonctionnel
et/ou sécurité) qui étaient rejetés pour cause de besoin d'émuler au
mieux le fonctionnement d'IE et d'éviter ainsi les utilisateurs remontant
ce qui leur semble être un bug ("ça marche sous IE mais pas sous Opera")
alors que c'est le comportement W3C-compliant ou "naturel" ...
Mouais ... Là encore, le quasi-monopole d'IE entre en compte.
D'un côté, il est vrai que Opera a longtemps manqué de fonctionnalités exotiques (certains plugins, le DHTML, ...). D'un autre côté, il m'est arrivé de remonter aux développeurs d'Opera des bugs (fonctionnel et/ou sécurité) qui étaient rejetés pour cause de besoin d'émuler au mieux le fonctionnement d'IE et d'éviter ainsi les utilisateurs remontant ce qui leur semble être un bug ("ça marche sous IE mais pas sous Opera") alors que c'est le comportement W3C-compliant ou "naturel" ...
Nicob
Nicob
On Wed, 05 Nov 2003 22:56:45 +0100, AMcD wrote:
Prend l'exemple des skins : cela ne sert strictement à rien, consomme des resources, etc. Pourtant, va sur des sites qui proposent ce genre de trucs, les téléchargements se comptent par millions.
J'ai vu peu de failles de sécurité liées aux skins (sauf sous Windows Media Player, quel hasard !). Mais je trouve aberrant le comportement de certains navigateurs qui interpètent de l'HTML dès qu'ils le voient, sans se soucier du Content-Type ...
C'est ce type de "fonctionnalités" qui posent des problèmes de sécurité !
Un p'tit 0-day :
http://nicob.net/cgi-bin/content-type.cgi
Nicob
On Wed, 05 Nov 2003 22:56:45 +0100, AMcD wrote:
Prend l'exemple des skins : cela ne sert strictement à rien, consomme
des resources, etc. Pourtant, va sur des sites qui proposent ce genre de
trucs, les téléchargements se comptent par millions.
J'ai vu peu de failles de sécurité liées aux skins (sauf sous Windows
Media Player, quel hasard !). Mais je trouve aberrant le comportement de
certains navigateurs qui interpètent de l'HTML dès qu'ils le voient,
sans se soucier du Content-Type ...
C'est ce type de "fonctionnalités" qui posent des problèmes de sécurité !
Prend l'exemple des skins : cela ne sert strictement à rien, consomme des resources, etc. Pourtant, va sur des sites qui proposent ce genre de trucs, les téléchargements se comptent par millions.
J'ai vu peu de failles de sécurité liées aux skins (sauf sous Windows Media Player, quel hasard !). Mais je trouve aberrant le comportement de certains navigateurs qui interpètent de l'HTML dès qu'ils le voient, sans se soucier du Content-Type ...
C'est ce type de "fonctionnalités" qui posent des problèmes de sécurité !
Un p'tit 0-day :
http://nicob.net/cgi-bin/content-type.cgi
Nicob
Chambord
AMcD wrote: Le codeur
doit faire gaffe :
- Aux buffers overflows, - Aux stack overflows, - Aux string overflows, - Aux integer overflows.
Pour un défendeur de la langue française pure qui déteste l'anglomanie ?
"Aux buffers overflows" moi ça me fait rever je trouve ça poetik. :-) butterfly....over..flower...
AMcD wrote:
Le codeur
doit faire gaffe :
- Aux buffers overflows,
- Aux stack overflows,
- Aux string overflows,
- Aux integer overflows.
Pour un défendeur de la langue française pure qui
déteste l'anglomanie ?
"Aux buffers overflows" moi ça me fait rever je trouve ça poetik. :-)
butterfly....over..flower...
- Aux buffers overflows, - Aux stack overflows, - Aux string overflows, - Aux integer overflows.
Pour un défendeur de la langue française pure qui déteste l'anglomanie ?
"Aux buffers overflows" moi ça me fait rever je trouve ça poetik. :-) butterfly....over..flower...
Laurent Wacrenier
AMcD écrit:
Ha, et tes solutions ? Tu programmes un peu ?
Oui, entre autre, je maintiens des serveurs de livraison et de lecture de courrier de 22000 lignes sans beaucoup de commentaires. Alors quand j'entends qu'il faut passer des mois*hommes avant de concevoir la moindre chose de plus de 1000 lignes, je me marre.
Tiens voici un petit exemple de la difficulté de coder 100% sûr. Suppose que tu aies à implémenter une routine de transaction simple via un réseau. Allez, dison le Net. Le codeur doit faire gaffe :
- Aux buffers overflows, - Aux stack overflows, - Aux string overflows, - Aux integer overflows.
Je ne me rappele pas avoir des bugs avec ça, ni des autres plus bas car je tourne sur une plateforme securisée (non Microsoft). On doit surtout faire gaffe aux spécifications, si elles sont bien faites, le reste va de l'allant.
Pas de fatalité ? Tant que les facteurs de décision seront basés sur la rentabilité, j'en doute...
C'est bien pour ça que mes programmes sont en GPL.
AMcD <arnold.mcdonald@free.fr> écrit:
Ha, et tes solutions ? Tu programmes un peu ?
Oui, entre autre, je maintiens des serveurs de livraison et de lecture
de courrier de 22000 lignes sans beaucoup de commentaires. Alors quand
j'entends qu'il faut passer des mois*hommes avant de concevoir la
moindre chose de plus de 1000 lignes, je me marre.
Tiens voici un petit exemple
de la difficulté de coder 100% sûr. Suppose que tu aies à implémenter une
routine de transaction simple via un réseau. Allez, dison le Net. Le codeur
doit faire gaffe :
- Aux buffers overflows,
- Aux stack overflows,
- Aux string overflows,
- Aux integer overflows.
Je ne me rappele pas avoir des bugs avec ça, ni des autres plus bas
car je tourne sur une plateforme securisée (non Microsoft). On doit
surtout faire gaffe aux spécifications, si elles sont bien faites, le
reste va de l'allant.
Pas de fatalité ? Tant que les facteurs de décision seront basés sur la
rentabilité, j'en doute...
C'est bien pour ça que mes programmes sont en GPL.
Oui, entre autre, je maintiens des serveurs de livraison et de lecture de courrier de 22000 lignes sans beaucoup de commentaires. Alors quand j'entends qu'il faut passer des mois*hommes avant de concevoir la moindre chose de plus de 1000 lignes, je me marre.
Tiens voici un petit exemple de la difficulté de coder 100% sûr. Suppose que tu aies à implémenter une routine de transaction simple via un réseau. Allez, dison le Net. Le codeur doit faire gaffe :
- Aux buffers overflows, - Aux stack overflows, - Aux string overflows, - Aux integer overflows.
Je ne me rappele pas avoir des bugs avec ça, ni des autres plus bas car je tourne sur une plateforme securisée (non Microsoft). On doit surtout faire gaffe aux spécifications, si elles sont bien faites, le reste va de l'allant.
Pas de fatalité ? Tant que les facteurs de décision seront basés sur la rentabilité, j'en doute...
C'est bien pour ça que mes programmes sont en GPL.
AMcD
Laurent Wacrenier wrote:
AMcD écrit:
Ha, et tes solutions ? Tu programmes un peu ?
Oui, entre autre, je maintiens des serveurs de livraison et de lecture de courrier de 22000 lignes sans beaucoup de commentaires. Alors quand j'entends qu'il faut passer des mois*hommes avant de concevoir la moindre chose de plus de 1000 lignes, je me marre.
22.000 lignes ? Ouah, je suis impressionné, c'est ce qu'il me faut pour un memory trainer pour Diablo II...
Un OS c'est des millions de lignes de code, c'est autre chose que quelques malheureux milliers de lignes pour un serveur POP/SMTP. Et surtout d'une bien plus grande complexité que l'utilisation de librairies satndards au code éprouvé depuis 15 ans (cas d'applis de courrier). Qui plus est, 22K lignes sans beaucoup de commentaires, c'est de la daube : c'est inmaintenable et aucune boîte sérieuse refusera un tel travail. De toute façon, 22.000 lignes pour un serveur de courrier, je doute que ce soit l'oeuvre d'un professionnel...
Je ne me rappele pas avoir des bugs avec ça, ni des autres plus bas car je tourne sur une plateforme securisée (non Microsoft). On doit surtout faire gaffe aux spécifications, si elles sont bien faites, le reste va de l'allant.
Mais oui, mais oui, Linux power on a compris. Si t'as jamais eu un buffer overflow dans ta vie, tu dois pas coder depuis bien longtemps ! MDR. Fais une application critique pour une boîte qui gagne pleins de sous online avec, on va voir si tes applis de 22K seront sans beaucoup de commentaires et si tu connaîtras pas les joies d'un DoS...
Pas de fatalité ? Tant que les facteurs de décision seront basés sur la rentabilité, j'en doute...
C'est bien pour ça que mes programmes sont en GPL.
Allez, tu m'as assez fait rire, moi aussi je bosse avec GPL, regarde : braGgart Plonk List...
-- AMcD
http://arnold.mcdonald.free.fr/
Laurent Wacrenier wrote:
AMcD <arnold.mcdonald@free.fr> écrit:
Ha, et tes solutions ? Tu programmes un peu ?
Oui, entre autre, je maintiens des serveurs de livraison et de lecture
de courrier de 22000 lignes sans beaucoup de commentaires. Alors quand
j'entends qu'il faut passer des mois*hommes avant de concevoir la
moindre chose de plus de 1000 lignes, je me marre.
22.000 lignes ? Ouah, je suis impressionné, c'est ce qu'il me faut pour un
memory trainer pour Diablo II...
Un OS c'est des millions de lignes de code, c'est autre chose que quelques
malheureux milliers de lignes pour un serveur POP/SMTP. Et surtout d'une
bien plus grande complexité que l'utilisation de librairies satndards au
code éprouvé depuis 15 ans (cas d'applis de courrier). Qui plus est, 22K
lignes sans beaucoup de commentaires, c'est de la daube : c'est
inmaintenable et aucune boîte sérieuse refusera un tel travail. De toute
façon, 22.000 lignes pour un serveur de courrier, je doute que ce soit
l'oeuvre d'un professionnel...
Je ne me rappele pas avoir des bugs avec ça, ni des autres plus bas
car je tourne sur une plateforme securisée (non Microsoft). On doit
surtout faire gaffe aux spécifications, si elles sont bien faites, le
reste va de l'allant.
Mais oui, mais oui, Linux power on a compris. Si t'as jamais eu un buffer
overflow dans ta vie, tu dois pas coder depuis bien longtemps ! MDR. Fais
une application critique pour une boîte qui gagne pleins de sous online
avec, on va voir si tes applis de 22K seront sans beaucoup de commentaires
et si tu connaîtras pas les joies d'un DoS...
Pas de fatalité ? Tant que les facteurs de décision seront basés sur
la rentabilité, j'en doute...
C'est bien pour ça que mes programmes sont en GPL.
Allez, tu m'as assez fait rire, moi aussi je bosse avec GPL, regarde :
braGgart Plonk List...
Oui, entre autre, je maintiens des serveurs de livraison et de lecture de courrier de 22000 lignes sans beaucoup de commentaires. Alors quand j'entends qu'il faut passer des mois*hommes avant de concevoir la moindre chose de plus de 1000 lignes, je me marre.
22.000 lignes ? Ouah, je suis impressionné, c'est ce qu'il me faut pour un memory trainer pour Diablo II...
Un OS c'est des millions de lignes de code, c'est autre chose que quelques malheureux milliers de lignes pour un serveur POP/SMTP. Et surtout d'une bien plus grande complexité que l'utilisation de librairies satndards au code éprouvé depuis 15 ans (cas d'applis de courrier). Qui plus est, 22K lignes sans beaucoup de commentaires, c'est de la daube : c'est inmaintenable et aucune boîte sérieuse refusera un tel travail. De toute façon, 22.000 lignes pour un serveur de courrier, je doute que ce soit l'oeuvre d'un professionnel...
Je ne me rappele pas avoir des bugs avec ça, ni des autres plus bas car je tourne sur une plateforme securisée (non Microsoft). On doit surtout faire gaffe aux spécifications, si elles sont bien faites, le reste va de l'allant.
Mais oui, mais oui, Linux power on a compris. Si t'as jamais eu un buffer overflow dans ta vie, tu dois pas coder depuis bien longtemps ! MDR. Fais une application critique pour une boîte qui gagne pleins de sous online avec, on va voir si tes applis de 22K seront sans beaucoup de commentaires et si tu connaîtras pas les joies d'un DoS...
Pas de fatalité ? Tant que les facteurs de décision seront basés sur la rentabilité, j'en doute...
C'est bien pour ça que mes programmes sont en GPL.
Allez, tu m'as assez fait rire, moi aussi je bosse avec GPL, regarde : braGgart Plonk List...
-- AMcD
http://arnold.mcdonald.free.fr/
AMcD
ppc wrote:
AMcD wrote: Le codeur
doit faire gaffe :
- Aux buffers overflows, - Aux stack overflows, - Aux string overflows, - Aux integer overflows.
Pour un défendeur de la langue française pure qui déteste l'anglomanie ?
Débordement de tampon, de pile, de chaîne et d'entier. Tu sais, en informatique on traduit rarement les termes techniques. Mais bon, je veux bien te faire plaisir :o).
-- AMcD
http://arnold.mcdonald.free.fr/
ppc wrote:
AMcD wrote:
Le codeur
doit faire gaffe :
- Aux buffers overflows,
- Aux stack overflows,
- Aux string overflows,
- Aux integer overflows.
Pour un défendeur de la langue française pure qui
déteste l'anglomanie ?
Débordement de tampon, de pile, de chaîne et d'entier. Tu sais, en
informatique on traduit rarement les termes techniques. Mais bon, je veux
bien te faire plaisir :o).
- Aux buffers overflows, - Aux stack overflows, - Aux string overflows, - Aux integer overflows.
Pour un défendeur de la langue française pure qui déteste l'anglomanie ?
Débordement de tampon, de pile, de chaîne et d'entier. Tu sais, en informatique on traduit rarement les termes techniques. Mais bon, je veux bien te faire plaisir :o).
-- AMcD
http://arnold.mcdonald.free.fr/
Roland Garcia
On Wed, 05 Nov 2003 22:56:45 +0100, AMcD wrote:
Prend l'exemple des skins : cela ne sert strictement à rien, consomme des resources, etc. Pourtant, va sur des sites qui proposent ce genre de trucs, les téléchargements se comptent par millions.
J'ai vu peu de failles de sécurité liées aux skins (sauf sous Windows Media Player, quel hasard !). Mais je trouve aberrant le comportement de certains navigateurs qui interpètent de l'HTML dès qu'ils le voient, sans se soucier du Content-Type ...
C'est ce type de "fonctionnalités" qui posent des problèmes de sécurité !
Un p'tit 0-day :
http://nicob.net/cgi-bin/content-type.cgi
Ah, quand même !
Le problème est dans les fonctionnalités absurdes à la Microsoft, pas dans les overflow_machin qui eux touchent tout le monde. On a même inventé les fonctionnalités absurdes dans les anti-virus, rajoutant une couche à celles de Microsoft.......
Roland Garcia
On Wed, 05 Nov 2003 22:56:45 +0100, AMcD wrote:
Prend l'exemple des skins : cela ne sert strictement à rien, consomme
des resources, etc. Pourtant, va sur des sites qui proposent ce genre de
trucs, les téléchargements se comptent par millions.
J'ai vu peu de failles de sécurité liées aux skins (sauf sous Windows
Media Player, quel hasard !). Mais je trouve aberrant le comportement de
certains navigateurs qui interpètent de l'HTML dès qu'ils le voient,
sans se soucier du Content-Type ...
C'est ce type de "fonctionnalités" qui posent des problèmes de sécurité !
Un p'tit 0-day :
http://nicob.net/cgi-bin/content-type.cgi
Ah, quand même !
Le problème est dans les fonctionnalités absurdes à la Microsoft, pas
dans les overflow_machin qui eux touchent tout le monde. On a même
inventé les fonctionnalités absurdes dans les anti-virus, rajoutant une
couche à celles de Microsoft.......
Prend l'exemple des skins : cela ne sert strictement à rien, consomme des resources, etc. Pourtant, va sur des sites qui proposent ce genre de trucs, les téléchargements se comptent par millions.
J'ai vu peu de failles de sécurité liées aux skins (sauf sous Windows Media Player, quel hasard !). Mais je trouve aberrant le comportement de certains navigateurs qui interpètent de l'HTML dès qu'ils le voient, sans se soucier du Content-Type ...
C'est ce type de "fonctionnalités" qui posent des problèmes de sécurité !
Un p'tit 0-day :
http://nicob.net/cgi-bin/content-type.cgi
Ah, quand même !
Le problème est dans les fonctionnalités absurdes à la Microsoft, pas dans les overflow_machin qui eux touchent tout le monde. On a même inventé les fonctionnalités absurdes dans les anti-virus, rajoutant une couche à celles de Microsoft.......
Roland Garcia
AMcD
J'ai vu peu de failles de sécurité liées aux skins (sauf sous Windows Media Player, quel hasard !). Mais je trouve aberrant le comportement de certains navigateurs qui interpètent de l'HTML dès qu'ils le voient, sans se soucier du Content-Type ...
J'ai pris l'exemple des skins pour le côté inutile, par pour les failles :o).
C'est ce type de "fonctionnalités" qui posent des problèmes de sécurité !
C'est clair.
Un p'tit 0-day :
Tu n'es qu'un vil pirate :-).
-- AMcD
http://arnold.mcdonald.free.fr/
J'ai vu peu de failles de sécurité liées aux skins (sauf sous Windows
Media Player, quel hasard !). Mais je trouve aberrant le comportement
de certains navigateurs qui interpètent de l'HTML dès qu'ils le
voient,
sans se soucier du Content-Type ...
J'ai pris l'exemple des skins pour le côté inutile, par pour les failles
:o).
C'est ce type de "fonctionnalités" qui posent des problèmes de
sécurité !
J'ai vu peu de failles de sécurité liées aux skins (sauf sous Windows Media Player, quel hasard !). Mais je trouve aberrant le comportement de certains navigateurs qui interpètent de l'HTML dès qu'ils le voient, sans se soucier du Content-Type ...
J'ai pris l'exemple des skins pour le côté inutile, par pour les failles :o).
C'est ce type de "fonctionnalités" qui posent des problèmes de sécurité !
