D'après un article comptabilisant les annonces de failles de sécurité
des différents OS par Secunia : http://www.theinquirer.net/?article=13420
on a relevé en 2003 :
IBM OS/400 : zéro faille.
...
FreeBSD 5.x : 21 failles.
...
Noyau Linux 2.4.x : 10 failles.
Windows 2003 server : 15 failles.
Windows XP professional : 34 failles.
...
Redhat Linux 9 : 72 failles.
Redhat Linux 8 : 119 failles.
Mandrake Linux 9.x : 126 failles.
Ces chiffres sont à relativiser car ils ne comparent pas la même chose :
des distributions Linux comportant des milliers de logiciels, avec des
OS simples, voire le noyau seul. Néanmoins je crois qu'il faut rester
humble quand on dit que Linux est un système sûr... c'est loin d'être le
cas. D'après ce même article, 70% des failles trouvés en 2002 était sur
Linux et 50% des failles en 2003. Dans le même sens, on peut aussi
remarquer que le vieux redhat8 a plus de plus failles que le récent
redhat9. Donc ça s'améliore, mais il reste des progrès à faire....
PS : Afin de ne pas enfreindre ma résolution pour 2004, je ne cite pas
le nom ni les chiffres de la lanterne rouge.
Le mar 06 jan 2004 à 12:39, Manuel Leclerc a tapoté : | | > exether[linux] find . -type f -exec grep -H do_mremap {} ; | > exether[linux] uname -r | > 2.2.25 | | http://groups.google.com/groups?selmG5G-3mf-21%40gated-at.bofh.it | | Tu me diras si ça t'aide, je poste vite fait.
Nickel... Le patch 2.4.23->2.4.24 ne me disant rien j'étais entrain de récupérer le 2.4.24 pour voir le contexte et adapter... Merci.
Thomas -- #ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT 2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c
Le mar 06 jan 2004 à 12:39, Manuel Leclerc a tapoté :
|
| > exether[linux] find . -type f -exec grep -H do_mremap {} ;
| > exether[linux] uname -r
| > 2.2.25
|
| http://groups.google.com/groups?selmG5G-3mf-21%40gated-at.bofh.it
|
| Tu me diras si ça t'aide, je poste vite fait.
Nickel... Le patch 2.4.23->2.4.24 ne me disant rien j'étais entrain
de récupérer le 2.4.24 pour voir le contexte et adapter... Merci.
Thomas
--
#ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT
2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c
Le mar 06 jan 2004 à 12:39, Manuel Leclerc a tapoté : | | > exether[linux] find . -type f -exec grep -H do_mremap {} ; | > exether[linux] uname -r | > 2.2.25 | | http://groups.google.com/groups?selmG5G-3mf-21%40gated-at.bofh.it | | Tu me diras si ça t'aide, je poste vite fait.
Nickel... Le patch 2.4.23->2.4.24 ne me disant rien j'étais entrain de récupérer le 2.4.24 pour voir le contexte et adapter... Merci.
Thomas -- #ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT 2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c
talon
Benjamin FRANCOIS wrote:
Ouaf! Ca c'est la meilleure que tu ais sortie depuis longtemps! 22 -> 23 trou de sécurité dans le noyau 23 -> 24 trou de sécurité dans le noyau Combien à venir?
Il a dit *si aucune raison ne le justifie*. Un trou de sécurité c'est une raison qui justifie.
Oui, je suis un peu de mauvaise foi :-( Mais en fait comme il y a tout le temps des trous de sécurité il faut tout le temps upgrader, si bien que ça nullifie complètement l'adage "if it ain't broke ain't fix it" Sauf à supposer que la machine reste planquée dans un coin de la cave et ne voit jamais le vaste monde. Et encore ceci implique de ne bénéficier d'aucune des améliorations apportées par le travail des développeurs. Au total, à mon avis, la seule stratégie qui vaille c'est de tenir constamment la machine à jour, avec les dernières versions des programmes et les derniers patchs de sécurité, sauf excellente raison documentée comme quoi la dernière version en question est foireuse. C'est bien pourquoi je trouve la stratégie de Debian stable absolument nulle.
--
Michel TALON
Benjamin FRANCOIS <kwyxz@kwyxz.org> wrote:
Ouaf! Ca c'est la meilleure que tu ais sortie depuis longtemps!
22 -> 23 trou de sécurité dans le noyau
23 -> 24 trou de sécurité dans le noyau
Combien à venir?
Il a dit *si aucune raison ne le justifie*. Un trou de sécurité c'est
une raison qui justifie.
Oui, je suis un peu de mauvaise foi :-( Mais en fait comme il y a tout
le temps des trous de sécurité il faut tout le temps upgrader, si bien
que ça nullifie complètement l'adage
"if it ain't broke ain't fix it"
Sauf à supposer que la machine reste planquée dans un coin de la cave
et ne voit jamais le vaste monde. Et encore ceci implique de ne
bénéficier d'aucune des améliorations apportées par le travail des
développeurs.
Au total, à mon avis, la seule stratégie qui vaille c'est de tenir
constamment la machine à jour, avec les dernières versions des
programmes et les derniers patchs de sécurité, sauf excellente raison
documentée comme quoi la dernière version en question est foireuse.
C'est bien pourquoi je trouve la stratégie de Debian stable absolument
nulle.
Ouaf! Ca c'est la meilleure que tu ais sortie depuis longtemps! 22 -> 23 trou de sécurité dans le noyau 23 -> 24 trou de sécurité dans le noyau Combien à venir?
Il a dit *si aucune raison ne le justifie*. Un trou de sécurité c'est une raison qui justifie.
Oui, je suis un peu de mauvaise foi :-( Mais en fait comme il y a tout le temps des trous de sécurité il faut tout le temps upgrader, si bien que ça nullifie complètement l'adage "if it ain't broke ain't fix it" Sauf à supposer que la machine reste planquée dans un coin de la cave et ne voit jamais le vaste monde. Et encore ceci implique de ne bénéficier d'aucune des améliorations apportées par le travail des développeurs. Au total, à mon avis, la seule stratégie qui vaille c'est de tenir constamment la machine à jour, avec les dernières versions des programmes et les derniers patchs de sécurité, sauf excellente raison documentée comme quoi la dernière version en question est foireuse. C'est bien pourquoi je trouve la stratégie de Debian stable absolument nulle.
--
Michel TALON
geaorge
documentée comme quoi la dernière version en question est foireuse. C'est bien pourquoi je trouve la stratégie de Debian stable absolument nulle.
tros gros, mais vraiment trop gros
passeras pas :p
documentée comme quoi la dernière version en question est foireuse.
C'est bien pourquoi je trouve la stratégie de Debian stable absolument
nulle.
documentée comme quoi la dernière version en question est foireuse. C'est bien pourquoi je trouve la stratégie de Debian stable absolument nulle.
tros gros, mais vraiment trop gros
passeras pas :p
Sebastien Tanguy
Stephane TOUGARD writes:
Sebastien Tanguy wrote:
Quel dommage, dire ça alors que pile-poil, la dernière faille annoncée touche aussi bien les noyaux 2.4 que les 2.2 et 2.6 (élément de code n'ayant pas changé entre les 3 versions majeures).
Rien pour le moment sur http://www.linuxsecurity.com/advisories/debian.html ou http://www.linuxsecurity.com/advisories/slackware.html Tu as un pointeur ?
Vu qu'on faisait ça par revendeurs, je donne le troisième:
https://rhn.redhat.com/errata/RHSA-2003-417.html
Ceci dit, ce qui est vrai statistiquement peut etre faux dans un cas particulier. Il est evident que meme un noyau 2.2 a des trous de securite si on fouille vraiment. Le fait est que globalement on est quand meme moins emmerde.
Les mêmes statistiques qui comparent OS/400 et Mandrake 9.0 ?
seb. -- ``...God...root... what is difference ?'' --- Pitr, User Friendly 1998/11/11
Stephane TOUGARD <stephane@unices.org> writes:
Sebastien Tanguy wrote:
Quel dommage, dire ça alors que pile-poil, la dernière faille annoncée
touche aussi bien les noyaux 2.4 que les 2.2 et 2.6 (élément de code
n'ayant pas changé entre les 3 versions majeures).
Rien pour le moment sur
http://www.linuxsecurity.com/advisories/debian.html
ou
http://www.linuxsecurity.com/advisories/slackware.html
Tu as un pointeur ?
Vu qu'on faisait ça par revendeurs, je donne le troisième:
https://rhn.redhat.com/errata/RHSA-2003-417.html
Ceci dit, ce qui est vrai statistiquement peut etre faux dans un cas
particulier. Il est evident que meme un noyau 2.2 a des trous de
securite si on fouille vraiment. Le fait est que globalement on est
quand meme moins emmerde.
Les mêmes statistiques qui comparent OS/400 et Mandrake 9.0 ?
seb.
--
``...God...root... what is difference ?''
--- Pitr, User Friendly 1998/11/11
Quel dommage, dire ça alors que pile-poil, la dernière faille annoncée touche aussi bien les noyaux 2.4 que les 2.2 et 2.6 (élément de code n'ayant pas changé entre les 3 versions majeures).
Rien pour le moment sur http://www.linuxsecurity.com/advisories/debian.html ou http://www.linuxsecurity.com/advisories/slackware.html Tu as un pointeur ?
Vu qu'on faisait ça par revendeurs, je donne le troisième:
https://rhn.redhat.com/errata/RHSA-2003-417.html
Ceci dit, ce qui est vrai statistiquement peut etre faux dans un cas particulier. Il est evident que meme un noyau 2.2 a des trous de securite si on fouille vraiment. Le fait est que globalement on est quand meme moins emmerde.
Les mêmes statistiques qui comparent OS/400 et Mandrake 9.0 ?
seb. -- ``...God...root... what is difference ?'' --- Pitr, User Friendly 1998/11/11
Richard Delorme
Michel Talon wrote:
Je ne vois aucune raison d'upgrader un noyau si aucune raison ne le justifie. Ne jamais toucher a ce qui marche.
Ouaf! Ca c'est la meilleure que tu ais sortie depuis longtemps! 22 -> 23 trou de sécurité dans le noyau 23 -> 24 trou de sécurité dans le noyau Combien à venir?
2.2.2x -> rien du tout parce qu'il n'y a pas de trou de securite dans le noyau, qu'il fonctionne tres bien, est tres stable et repond aux besoins fonctionnels d'un serveur sans le moindre probleme.
Le dernier trou de sécurité, celui du 05/01/2004 (hier) touchant mremap(), affecte les noyaux 2.2.x, 2.4.x et 2.6.x, donc tu va devoir mettre à jour.
En 2003 les noyaux 2.2.x ont connus deux failles.
C'est mieux que le noyau 2.4.x mais ce n'est pas rien du tout.
-- Richard
Michel Talon wrote:
Je ne vois aucune raison d'upgrader un noyau si aucune raison ne le
justifie. Ne jamais toucher a ce qui marche.
Ouaf! Ca c'est la meilleure que tu ais sortie depuis longtemps!
22 -> 23 trou de sécurité dans le noyau
23 -> 24 trou de sécurité dans le noyau
Combien à venir?
2.2.2x -> rien du tout parce qu'il n'y a pas de trou de securite dans le
noyau, qu'il fonctionne tres bien, est tres stable et repond aux besoins
fonctionnels d'un serveur sans le moindre probleme.
Le dernier trou de sécurité, celui du 05/01/2004 (hier) touchant
mremap(), affecte les noyaux 2.2.x, 2.4.x et 2.6.x, donc tu va devoir
mettre à jour.
En 2003 les noyaux 2.2.x ont connus deux failles.
C'est mieux que le noyau 2.4.x mais ce n'est pas rien du tout.
Je ne vois aucune raison d'upgrader un noyau si aucune raison ne le justifie. Ne jamais toucher a ce qui marche.
Ouaf! Ca c'est la meilleure que tu ais sortie depuis longtemps! 22 -> 23 trou de sécurité dans le noyau 23 -> 24 trou de sécurité dans le noyau Combien à venir?
2.2.2x -> rien du tout parce qu'il n'y a pas de trou de securite dans le noyau, qu'il fonctionne tres bien, est tres stable et repond aux besoins fonctionnels d'un serveur sans le moindre probleme.
Le dernier trou de sécurité, celui du 05/01/2004 (hier) touchant mremap(), affecte les noyaux 2.2.x, 2.4.x et 2.6.x, donc tu va devoir mettre à jour.
En 2003 les noyaux 2.2.x ont connus deux failles.
C'est mieux que le noyau 2.4.x mais ce n'est pas rien du tout.
-- Richard
Richard Delorme
On Mon, 05 Jan 2004 21:14:20 +0100, Richard Delorme wrote:
IBM OS/400 : zéro faille. ... FreeBSD 5.x : 21 failles. ... Noyau Linux 2.4.x : 10 failles. Windows 2003 server : 15 failles. Windows XP professional : 34 failles. ... Redhat Linux 9 : 72 failles. Redhat Linux 8 : 119 failles. Mandrake Linux 9.x : 126 failles.
Typiquement des chiffres pas comparables.
Tu en croises beaucoup des OS/400 sur Internet ? Combien de gens touchent à cet OS dans le monde ? 100, 1000 fois moins que de gens qui touchent à Linux ? Forcément, si l'OS en question n'est pas exposé aux intempéries, on aura du mal à savoir s'il prend l'eau ou pas.
Après, il faudrait prendre la peine de préciser ce que l'on compte comme failles dans les tois derniers chiffres. Amha, les auteurs ne se sont pas cassés la tête, ils ont compté les failles noyau + userland gnu + applis propriétaires.
Tu pourrais citer tes sources ? Merci...
Déjà fait, mais bon je recommence :
« D'après un article comptabilisant les annonces de failles de sécurité des différents OS par Secunia : http://www.theinquirer.net/?article420 on a relevé en 2003 : »
Tu peux aussi aller sur http://www.secunia.com pour voir le détail des failles.
-- Richard
On Mon, 05 Jan 2004 21:14:20 +0100, Richard Delorme <abulmo@nospam.fr>
wrote:
IBM OS/400 : zéro faille.
...
FreeBSD 5.x : 21 failles.
...
Noyau Linux 2.4.x : 10 failles.
Windows 2003 server : 15 failles.
Windows XP professional : 34 failles.
...
Redhat Linux 9 : 72 failles.
Redhat Linux 8 : 119 failles.
Mandrake Linux 9.x : 126 failles.
Typiquement des chiffres pas comparables.
Tu en croises beaucoup des OS/400 sur Internet ?
Combien de gens touchent à cet OS dans le monde ? 100, 1000 fois moins
que de gens qui touchent à Linux ?
Forcément, si l'OS en question n'est pas exposé aux intempéries, on
aura du mal à savoir s'il prend l'eau ou pas.
Après, il faudrait prendre la peine de préciser ce que l'on compte
comme failles dans les tois derniers chiffres. Amha, les auteurs ne se
sont pas cassés la tête, ils ont compté les failles noyau + userland
gnu + applis propriétaires.
Tu pourrais citer tes sources ? Merci...
Déjà fait, mais bon je recommence :
« D'après un article comptabilisant les annonces de failles de sécurité
des différents OS par Secunia : http://www.theinquirer.net/?article420
on a relevé en 2003 : »
Tu peux aussi aller sur http://www.secunia.com pour voir le détail des
failles.
On Mon, 05 Jan 2004 21:14:20 +0100, Richard Delorme wrote:
IBM OS/400 : zéro faille. ... FreeBSD 5.x : 21 failles. ... Noyau Linux 2.4.x : 10 failles. Windows 2003 server : 15 failles. Windows XP professional : 34 failles. ... Redhat Linux 9 : 72 failles. Redhat Linux 8 : 119 failles. Mandrake Linux 9.x : 126 failles.
Typiquement des chiffres pas comparables.
Tu en croises beaucoup des OS/400 sur Internet ? Combien de gens touchent à cet OS dans le monde ? 100, 1000 fois moins que de gens qui touchent à Linux ? Forcément, si l'OS en question n'est pas exposé aux intempéries, on aura du mal à savoir s'il prend l'eau ou pas.
Après, il faudrait prendre la peine de préciser ce que l'on compte comme failles dans les tois derniers chiffres. Amha, les auteurs ne se sont pas cassés la tête, ils ont compté les failles noyau + userland gnu + applis propriétaires.
Tu pourrais citer tes sources ? Merci...
Déjà fait, mais bon je recommence :
« D'après un article comptabilisant les annonces de failles de sécurité des différents OS par Secunia : http://www.theinquirer.net/?article420 on a relevé en 2003 : »
Tu peux aussi aller sur http://www.secunia.com pour voir le détail des failles.
-- Richard
Emmanuel Florac
Dans article <3ffa084a$0$6974$, disait...
Oui, mais il y a aussi le temps que le distributeur mettent la correction à disposition et surtout que les admins l'appliquent. Qui a installé le noyau 2.4.24 à la place du noyau 2.4.23 le jours de sa sortie (soit hier) ?
Je n'ai pas eu le temps mais vu la modestie des différences entre le .23 et le .24, je ne crois pas qu'il y ai de risque.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3ffa084a$0$6974$7a628cd7@news.club-internet.fr>,
abulmo@nospam.fr disait...
Oui, mais il y a aussi le temps que le distributeur mettent la
correction à disposition et surtout que les admins l'appliquent. Qui a
installé le noyau 2.4.24 à la place du noyau 2.4.23 le jours de sa
sortie (soit hier) ?
Je n'ai pas eu le temps mais vu la modestie des différences entre le .23
et le .24, je ne crois pas qu'il y ai de risque.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Oui, mais il y a aussi le temps que le distributeur mettent la correction à disposition et surtout que les admins l'appliquent. Qui a installé le noyau 2.4.24 à la place du noyau 2.4.23 le jours de sa sortie (soit hier) ?
Je n'ai pas eu le temps mais vu la modestie des différences entre le .23 et le .24, je ne crois pas qu'il y ai de risque.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Emmanuel Florac
Dans article <bte92h$1cr8$, disait...
Oui, je suis un peu de mauvaise foi :-( Mais en fait comme il y a tout le temps des trous de sécurité il faut tout le temps upgrader, si bien que ça nullifie complètement l'adage "if it ain't broke ain't fix it"
SI ta machine sert de serveur web et que seul apache est accessible de l'extérieur ( etrégulièrepment patché), en quoi ne pourrait-on conserver un 2.4.8 en service? Je ne vois pas.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <bte92h$1cr8$1@asmodee.lpthe.jussieu.fr>,
talon@lpthe.jussieu.fr disait...
Oui, je suis un peu de mauvaise foi :-( Mais en fait comme il y a tout
le temps des trous de sécurité il faut tout le temps upgrader, si bien
que ça nullifie complètement l'adage
"if it ain't broke ain't fix it"
SI ta machine sert de serveur web et que seul apache est accessible de
l'extérieur ( etrégulièrepment patché), en quoi ne pourrait-on conserver
un 2.4.8 en service? Je ne vois pas.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Oui, je suis un peu de mauvaise foi :-( Mais en fait comme il y a tout le temps des trous de sécurité il faut tout le temps upgrader, si bien que ça nullifie complètement l'adage "if it ain't broke ain't fix it"
SI ta machine sert de serveur web et que seul apache est accessible de l'extérieur ( etrégulièrepment patché), en quoi ne pourrait-on conserver un 2.4.8 en service? Je ne vois pas.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Jean-Francois Billaud
scripsit Emmanuel Florac :
Oui, mais il y a aussi le temps que le distributeur mettent la correction à disposition et surtout que les admins l'appliquent. Qui a installé le noyau 2.4.24 à la place du noyau 2.4.23 le jours de sa sortie (soit hier) ?
Je n'ai pas eu le temps mais vu la modestie des différences entre le .23 et le .24, je ne crois pas qu'il y ai de risque.
C'est ce qui ressort des discussions sur linux.kernel (Marcello n'a fait que peu de changements et tout le reste est parti dans 2.4.25-pre4)
Noter qu'une façon d'exploiter la vulnérabilité a été publiée ce matin.
Aux dermières nouvelles : 2.2 non vulnérable 2.4 < 2.4.24 vulnérable localement (root access) 2.6 < 2.6.1rc2 vulnérable localement (reboot)
JFB
-- Think of your family tonight. Try to crawl home after the computer crashes.
scripsit Emmanuel Florac :
Oui, mais il y a aussi le temps que le distributeur mettent la
correction à disposition et surtout que les admins l'appliquent. Qui a
installé le noyau 2.4.24 à la place du noyau 2.4.23 le jours de sa
sortie (soit hier) ?
Je n'ai pas eu le temps mais vu la modestie des différences entre le .23
et le .24, je ne crois pas qu'il y ai de risque.
C'est ce qui ressort des discussions sur linux.kernel (Marcello n'a fait
que peu de changements et tout le reste est parti dans 2.4.25-pre4)
Noter qu'une façon d'exploiter la vulnérabilité a été publiée ce matin.
Aux dermières nouvelles :
2.2 non vulnérable
2.4 < 2.4.24 vulnérable localement (root access)
2.6 < 2.6.1rc2 vulnérable localement (reboot)
JFB
--
Think of your family tonight.
Try to crawl home after the computer crashes.
Oui, mais il y a aussi le temps que le distributeur mettent la correction à disposition et surtout que les admins l'appliquent. Qui a installé le noyau 2.4.24 à la place du noyau 2.4.23 le jours de sa sortie (soit hier) ?
Je n'ai pas eu le temps mais vu la modestie des différences entre le .23 et le .24, je ne crois pas qu'il y ai de risque.
C'est ce qui ressort des discussions sur linux.kernel (Marcello n'a fait que peu de changements et tout le reste est parti dans 2.4.25-pre4)
Noter qu'une façon d'exploiter la vulnérabilité a été publiée ce matin.
Aux dermières nouvelles : 2.2 non vulnérable 2.4 < 2.4.24 vulnérable localement (root access) 2.6 < 2.6.1rc2 vulnérable localement (reboot)
JFB
-- Think of your family tonight. Try to crawl home after the computer crashes.
Miod Vallat
Le dernier trou de sécurité, celui du 05/01/2004 (hier) touchant mremap(), affecte les noyaux 2.2.x, 2.4.x et 2.6.x, donc tu va devoir mettre à jour.
Non, il n'affecte pas les 2.2, c'est une conclusion un peu hâtive qui a été infirmée un peu plus tard.
Le dernier trou de sécurité, celui du 05/01/2004 (hier) touchant
mremap(), affecte les noyaux 2.2.x, 2.4.x et 2.6.x, donc tu va devoir
mettre à jour.
Non, il n'affecte pas les 2.2, c'est une conclusion un peu hâtive qui a
été infirmée un peu plus tard.
