Discussion :

[lavazavio]

Une faille critique dans les versions de kernel Linux qui permet de passer root
les versions affectées sont comprises entre la 2.6.37 et la 3.8.8


Le 14 mai 2013 a été publiée la découverte d'une faille dans le kernel Linux permettant de passer root à partir d'un compte utilisateur, et ce, même en cas d'exploit d'une faille d'application web !

Cette faille touche les versions de kernel comprises entre la 2.6.37 et la 3.8.8. Elle s'appuie sur l'option "CONFIG_PERF_EVENTS" compilée dans le noyau et résulte d'une erreur présente au niveau du fichier "fs/proc/base.c".

Parmi les distributions affectées par cette faille, on trouve la fraichement sortie Debian Wheezy, les versions d'Ubuntu à partir de la 12.04 LTS, Red Hat 6.3, Centos 6.3.

Des distributions ont déjà réagi et publié des patchs correctifs.

Pensez donc à mettre à jour vos kernels !

Sources :
exploit-db
h-online
Debian
Ubuntu

[Katyucha]

FAUX pour la RHEL6

Le noyau d'une RHEL 6.3 est "2.6.32" donc pas affecté.

Vala !

[Ozwald]

Le 14 mai 2013 a été publiée la découverte d'une faille dans le kernel Linux permettant de passer root à partir d'un compte utilisateur, et ce, même en cas d'exploit d'une faille d'application web !

Je trouve la tournure assez peu pertinente : la vulnérabilité en question est une élévation de privilège local, exploitable quand on a de l'exécution de code sur une machine linux dont le noyau est vulnérable. Que cette possibilité d'exécution de code provienne d'un accès légitime, frauduleux, physique, ou à distance n'a pas d'importance dans l'histoire et je ne vois donc pas l'intérêt de la précision que j'ai mise en gras ci-dessus...C'est pour faire du sensationnel ?

FAUX pour la RHEL6

Le noyau d'une RHEL 6.3 est "2.6.32" donc pas affecté.

Red Hat a la facheuse manie de backporter énormément de patch sans incrémenter les versions (pas uniquement sur le noyau d'ailleurs, je sais qu'ils le font au moins également pour Apache). Le noyau RHEL6 est donc bien un "2.6.32" comme vous le dite mais il est loin d'être vanilla et, en l'espèce, le code vulnérable avait bel et bien été backporté :
https://rhn.redhat.com/errata/RHSA-2013-0832.html
https://bugzilla.redhat.com/show_bug.cgi?id=962792#c6

Les utilisateurs de RHEL6 sont donc vulnérable tant qu'ils n'auront pas installé le patch

[chaval]

Je trouve la tournure assez peu pertinente : la vulnérabilité en question est une élévation de privilège local, exploitable quand on a de l'exécution de code sur une machine linux dont le noyau est vulnérable. Que cette possibilité d'exécution de code provienne d'un accès légitime, frauduleux, physique, ou à distance n'a pas d'importance dans l'histoire et je ne vois donc pas l'intérêt de la précision que j'ai mise en gras ci-dessus...C'est pour faire du sensationnel ?

Parcequ'il est très facile d'uploader un webshell depuis une application web mal codée (des sociétés prennent souvent des stagiaires pour développer des "petits sites web").
Une fois le webshell déposé, cela revient à avoir un accès local avec l'utilisateur qui fait fonctionner ton serveur web

Red Hat a la facheuse manie de backporter énormément de patch sans incrémenter les versions (pas uniquement sur le noyau d'ailleurs, je sais qu'ils le font au moins également pour Apache). Le noyau RHEL6 est donc bien un "2.6.32" comme vous le dite mais il est loin d'être vanilla et, en l'espèce, le code vulnérable avait bel et bien été backporté :
https://rhn.redhat.com/errata/RHSA-2013-0832.html
https://bugzilla.redhat.com/show_bug.cgi?id=962792#c6

Les utilisateurs de RHEL6 sont donc vulnérable tant qu'ils n'auront pas installé le patch

Ce n'est pas une fâcheuse manie, c'est leur façon de fonctionner : lors de la création d'une version majeure (5.0, 6.0, ...), les versions de paquets sont gelés. Ensuite, pendant la vie de la version stable (une dizaine d'années), Redhat s'engage à rétroporter les corrections de bugs dans chaque package. Etant donné qu'ils mettent à disposition des packages dont la version est figée depuis la version majeure, mais avec des correctifs "maison", ils laissent le même numéro de version, et ils incrémentent le numéro de publication.
Cela permet d'avoir moins de risque à appliquer des mises à jour dans les versions majeures. On est sur qu'il n'y a pas de modifs dans les fichiers de configuration (pas d'ajout d'une directive qui, lorsqu'elle n'est pas définie, provoque le non démarrage d'un démon), pas de nouvelle fonctionnalité à tester... Ca juste marche ;-)

[Ozwald]

Parcequ'il est très facile d'uploader un webshell depuis une application web mal codée (des sociétés prennent souvent des stagiaires pour développer des "petits sites web").
Une fois le webshell déposé, cela revient à avoir un accès local avec l'utilisateur qui fait fonctionner ton serveur web

Encore une fois : que l'accès à de l'exécution de code soit obtenue de telle ou telle façon n'a strictement aucune importance sur la vulnérabilité dont on parle. Je me demande donc toujours pourquoi on a eu cette précision là et pas une de celles-ci :

• et ce, même en cas d'hébegrement mutualisé.
• et ce, même en cas d'utilisation d'un chroot.
• et ce, même si vous avez mangé des petits pois à midi.
• ...

Mais bon...chacun rédige comme il l'entend et j'imagine que laisser supposer qu'on peut se faire poutrer depuis le web avec cette vuln ça sonne mieux

Ensuite, pendant la vie de la version stable (une dizaine d'années), Redhat s'engage à rétroporter les corrections de bugs dans chaque package.

Sauf qu'ils ne backportent pas que les corrections de bugs
Toujours dans le cas de la vulnérabilité dont on parle ici le code vulnérable a été introduit dans la version 2.6.37 du noyau, et plus précisément dans le commit suivant : http://git.kernel.org/cgit/linux/ker...7cadc96099fa13

Or ce commit n'est pas une correction de bug mais une modification interne iso-fonctionnelle préparant à des améliorations futures. Si RH ne backportaient que les bugs on pourrait légitimement penser que ce patch n'a aucune raison d'être dans leur noyau "2.6.32". Et c'est justement parce qu'on ne sait jamais simplement ce que RH a backporté et ce qu'ils n'ont pas backporté que j'ai utilisé l'expression "facheuse manie". L'expression est sans doute trop forte mais j'ai perdu tellement de temps à chercher si, oui ou non, une RH était vulnérable à telle ou telle faille que j'ai grossi le trait