Actuellement j'ai le noyau 2.6.22.9-desktop-1mdv qui semble très bien
marcher.
Admettons que pour d'obscures raison il me vient l'idée de le mettre à jour,
comme proposé depuis des lustres par le gestionnaire graphique de logiciel.
Si on résume tout ce qui a été dit sur le sujet depuis le début (voir même
avant) je peux me permettre de laisser cocher les
cases "kernel-desktop-2.6.22.18-1mdv" et "kernel-desktop-latest" à partir
du gestionnaire de mise à jour graphique pour que ça se mette à jour?
Ou vaut-il mieux passer en ligne de commande? (auquel cas j'attendrais une
nouvelle version de ma distribution.)
Au cas où ça planterait, pourrais toujours booter sur le noyau 2.6.22.9 et
retrouver tout comme avant.
(ps : je me souviens un jour où j'avais fait cette manip et j'avais du tout
réinstaller, mais bon tant pis...)
On Sun, 30 Mar 2008 18:44:42 +0200, Pascal Hambourg :
L'ennui c'est que maintenant elle est connue, et très facile à exploiter localement pour passer root avec un noyau vulnérable.
Justement, n'y a-t-il pas un test simple, que tout un chacun peut lancer sur sa machine pour vérifier si le noyau contient, ou pas, la faille ?
Pascal Hambourg
[faille vmsplice]
Justement, n'y a-t-il pas un test simple, que tout un chacun peut lancer sur sa machine pour vérifier si le noyau contient, ou pas, la faille ?
Il existe dans la nature un programme de test qui donne accès à un shell root si le noyau est vulnérable, trouvable par une recherche avec les mots-clés "Linux vmsplice Local Root Exploit". Exemple : <http://www.milw0rm.com/exploits/5092>
Une version modifiée permet même de fermer la faille en désactivant l'appel système en cause : <http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c>
[faille vmsplice]
Justement, n'y a-t-il pas un test simple, que tout un chacun peut
lancer sur sa machine pour vérifier si le noyau contient, ou pas, la
faille ?
Il existe dans la nature un programme de test qui donne accès à un shell
root si le noyau est vulnérable, trouvable par une recherche avec les
mots-clés "Linux vmsplice Local Root Exploit".
Exemple : <http://www.milw0rm.com/exploits/5092>
Une version modifiée permet même de fermer la faille en désactivant
l'appel système en cause :
<http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c>
Justement, n'y a-t-il pas un test simple, que tout un chacun peut lancer sur sa machine pour vérifier si le noyau contient, ou pas, la faille ?
Il existe dans la nature un programme de test qui donne accès à un shell root si le noyau est vulnérable, trouvable par une recherche avec les mots-clés "Linux vmsplice Local Root Exploit". Exemple : <http://www.milw0rm.com/exploits/5092>
Une version modifiée permet même de fermer la faille en désactivant l'appel système en cause : <http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploitable.c>
Nicolas George
Pascal Hambourg wrote in message <fsojks$22td$:
Une version modifiée permet même de fermer la faille en désactivant l'appel système en cause :
Attention, le système devient instable après ça, avec des plantages et des corruptions de filesystem.
Pascal Hambourg wrote in message <fsojks$22td$1@biggoron.nerim.net>:
Une version modifiée permet même de fermer la faille en désactivant
l'appel système en cause :
Attention, le système devient instable après ça, avec des plantages et des
corruptions de filesystem.
Une version modifiée permet même de fermer la faille en désactivant l'appel système en cause :
Attention, le système devient instable après ça, avec des plantages et des corruptions de filesystem.
Pascal Hambourg
Pascal Hambourg wrote in message <fsojks$22td$:
Une version modifiée permet même de fermer la faille en désactivant l'appel système en cause :
Attention, le système devient instable après ça, avec des plantages et des corruptions de filesystem.
Oups, effectivement j'aurais dû lire la suite de <http://bugs.debian.org/cgi-bin/bugreport.cgi?bugF4953> avant de répondre. D'ailleurs il semble que ça ne concerne pas seulement la version modifiée mais aussi la version originelle qui ne fait que tester.
Pascal Hambourg wrote in message <fsojks$22td$1@biggoron.nerim.net>:
Une version modifiée permet même de fermer la faille en désactivant
l'appel système en cause :
Attention, le système devient instable après ça, avec des plantages et des
corruptions de filesystem.
Oups, effectivement j'aurais dû lire la suite de
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bugF4953> avant de
répondre. D'ailleurs il semble que ça ne concerne pas seulement la
version modifiée mais aussi la version originelle qui ne fait que tester.
Une version modifiée permet même de fermer la faille en désactivant l'appel système en cause :
Attention, le système devient instable après ça, avec des plantages et des corruptions de filesystem.
Oups, effectivement j'aurais dû lire la suite de <http://bugs.debian.org/cgi-bin/bugreport.cgi?bugF4953> avant de répondre. D'ailleurs il semble que ça ne concerne pas seulement la version modifiée mais aussi la version originelle qui ne fait que tester.
Fabien LE LEZ
On Sun, 30 Mar 2008 20:20:54 +0200, Pascal Hambourg :
D'ailleurs il semble que ça ne concerne pas seulement la version modifiée mais aussi la version originelle qui ne fait que tester.
Donc, pour résumer, on ne peut pas vérifier directement la présence de la faille sur une machine en production ?
On Sun, 30 Mar 2008 20:20:54 +0200, Pascal Hambourg :
D'ailleurs il semble que ça ne concerne pas seulement la
version modifiée mais aussi la version originelle qui ne fait que tester.
Donc, pour résumer, on ne peut pas vérifier directement la présence de
la faille sur une machine en production ?
