Liens connexes

Dépêche modérée par

Dépêche éditée par

: Faille de sécurité critique dans les noyaux 2.4 et 2.6

Posté par Jean-Christophe Berthon (page perso, ). Modéré le 07 août 2004.
0
Une faille de sécurité vient d'être découverte par l'organisation non-commerciale iSEC Security Research dans les noyaux <=2.4.26 et <=2.6.7.
La vulnérabilité se trouve dans le code gérant les pointeurs de position dans les fichiers 64bit. Ainsi n'importe quel processus utilisant ce bug pourrait lire des pages entières de la mémoire du noyau.

Les correctifs pour la RedHat Enterprise Linux sont déjà en ligne.
Pour la branche 2.4, la version 2.4.27-rc5 (qui devrait dans quelques jours être stable) corrige déjà le problème.
Mise à jour : le 2.4.27 est sorti. Voici le changelog.

> Lire la suite (58 commentaires, moyenne: 2,3).   [dépêche : 713 caractères]

Détails :
Cette vulnérabilité ne peut être exploitée qu'en local (d'après ce que j'ai pu lire). Elle s'applique à la tête de lecture 64 bits des fichiers. (voir le champ "file offset" de la fonction lseek(2))
Les noyaux récents de Linux ont deux API pour la gestion des fichiers: l'ancienne API 32 bits et la nouvelle (LFS) 64 bits. La présence de plusieurs conversions invalides entre pointeur de position 64 et 32 bits est en partie à l'origine de ce bug.
Beaucoup d'entrées de /proc y sont vulnérables.

Exploitation :
Une exploitation réussie pourrait conduire à lire les mots de passe hachés et même le mot de passe lors d'une connexion SSH (voir le lien sur la vulnérabilité iSEC)

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

[+] Je suis loutré

Posté par Ramón Perez (page perso, ) le 07/08/2004 à 11:29. (lien). Évalué à -10.

.

Re:

Posté par 007 () le 07/08/2004 à 11:41. (lien). Évalué à 7.

Pour ceux qui ont un 2.6, le correctif existe pour Fedora (basé sur un 2.6.8-rc1-bk5) :
http://www.fedoranews.org/updates/FEDORA-2004-247.shtml(...)

Le patch est assez gros :
$ diffstat linux-2.6.7-ppos.patch | tail -1
64 files changed, 1036 insertions(+), 590 deletions(-)

Pas d'affolement !

Posté par Pierre Jarillon (page perso, ) le 07/08/2004 à 12:05. (lien). Évalué à 9.

Si les administrateurs système sont directement concernés, cette vulnérabilité n'est pas catastrophique pour la plupart des utilisateurs. Elle n'est importante que pour ceux qui ont plusieurs comptes sur la machine avec des utilisateurs distants.
Rappelons-le, l'accès physique à la machine est la première vulnérabilité de tout système.

J'suis perplexe

Posté par Christophe Merlet (page perso, ) le 07/08/2004 à 12:14. (lien). Évalué à 8.

C'est une nouvelle mode d'annoncer les failles de sécurité avec les exploits qui vont bien avant qu'un correctif officiel (ie 2.4.27 et 2.6.8) soit dispo ?

Là ils annoncent une faille affectant le 2.6.7 et le 2.4.26 sans fournir le patch le corrigeant mais en fournissant le code de l'exploit !

ça ne me parait pas trés professionnel comme comportemant :(

Existe-t-il un patch pour le noyau 2.4?

Posté par capicapio () le 07/08/2004 à 12:22. (lien). Évalué à 3.

Salut,
Pour ceux qui ne veulent/peuvent pas attendre la sortie du 2.4.7 mais qui savent recompiler un noyau, la correction de cette faille est-elle dispo quelque part?

faille

Posté par warmup031 () le 07/08/2004 à 13:59. (lien). Évalué à 0.

franchement ça me saoul de devoir recompiler mon kernel tous les 4 matins
chak fois kilia une faille...
je viens de passer en 2.6.7 ce matin... et g pas envie de me coltiner encore
une compilation de kernel...
J'attendrai que ma distrib veuille bien s'upgrader et foutre ce patch...
Si une faille est découverte c'est normal qu'on puisse trouver l'exploit sur le web avant un patch correctif... le kernel il est libre nan ?? la faille aussi !! contrairement
au softs proprio

Doi-on fournir le code de l'exploit avant le patch?

Posté par Jean-Christophe Berthon (page perso, ) le 08/08/2004 à 22:55. (lien). Évalué à 2.

Cette question semble à l'origine de nombreux débats.

Je crois pour ma part que dans le monde du logiciel libre, n'importe quel volontaire peut être amené à corriger une faille de sécurité du noyau Linux à condition bien sûr qu'il en est les compétences.
Si un communiqué mentionne une nouvelle faille mais ne communique pas comment en tirer partie, comment voulez-vous que quelqu'un tente de trouver la partie fautive du code du noyau et la corriger?

Pour les logiciels OpenSource, ce type de scénario se reproduira encore à l'avenir. C'est un bon moyen pour faire participer la communauté OpenSource, dans son ensemble, au maintient de la sécurité des systèmes ouverts. Ainsi le niveau de réactivité ne peut-être qu'au mieux.

--
Jean-Christophe

[+] 2.4.27

Posté par Dalton joe (page perso, ) le 08/08/2004 à 23:52. (lien). Évalué à -2.

Je signale quand même que le 2.4.27 est sorti faut plus parler de la RC.
http://kerneltrap.org/node/view/3578(...)

grsecurity et cette vulnérabilité

Posté par Alexandre Dulaunoy (page perso, ) le 09/08/2004 à 09:22. (lien). Évalué à 4.

J'utilise sur plusieurs serveurs GNU/Linux le "patch" grsecurity (http://www.grsecurity.net/(...)) qui permet de rendre le noyau plus dur à certaines attaques. J'ai essayé l'exploit d'évaluation sur une machine 2.4.26-grsec (en mode high) avec quelques ACL (mais pas sur le /proc) et l'exploit évaluation a foiré. La raison ne semble pas claire si grsecurity est directement en cause mais cela semble fonctionner (dans le sens grsecurity joue son role) . Cela permet d'éviter plusieurs risques et l'installation n'est pas des plus compliquée (c'est un patch sur le noyau et ajoute une entrée dans le menu de configuration). Bien entendu, vous devez maintenir votre propre ligne de noyau mais il faut voir le rapport entre les deux... et choisir la bonne solution pour vos besoins.

Mise à jour du noyau 2.6 pour la faille

Posté par Jean-Christophe Berthon (page perso, ) le 10/08/2004 à 08:43. (lien). Évalué à 2.

Le noyau 2.6.8-rc4 vient de sortir, il pourrait être la dernière étape avant le noyau 2.6.8 final (http://kerneltrap.org/node/view/3619(...))
Donc, la faille devrait être corrigée rapidement pour la série 2.6 également.

Revenir en haut de page