Bonsoir à tous,
Pour ceux qui l'aurait loupé, une faille dans le Kernel branch 2.6.32 permet à minima de DoS la machine hôte et à maxima d'un gain de privilèges/exec de code.
Red Hat est dessus, informations dans leur bugzilla.
Tout est là, www.osvdb.org/show/osvdb/94706
Bon audit, A tte
Y'a encore de la prod en 2.6.32 ? </troll>
Plus sérieusement, des nouvelles d'un patch upstream ? je repousse depuis lundi mais j'ai pas trouvé en y regardant en diagonale. Pendant qu'on va de ce côté, des news d'une viabilité de lxc en mainstream à l'horizon ?
On 07/02/13 22:05, Leslie-Alexandre DENIS - DCforDATA wrote:
Bonsoir à tous,
Pour ceux qui l'aurait loupé, une faille dans le Kernel branch 2.6.32 permet à minima de DoS la machine hôte et à maxima d'un gain de privilèges/exec de code.
Red Hat est dessus, informations dans leur bugzilla.
Tout est là, www.osvdb.org/show/osvdb/94706
Bon audit, A tte _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le Tue, Jul 02, 2013 at 10:16:07PM +0200, Pierre Jaury a écrit:
Y'a encore de la prod en 2.6.32 ?
Les Debian Squeze, par exemple. Elles ne sont deprecated que depuis deux mois, et le passage de certains logiciels, par exemple php 5.3->5.4 ou mysql 5.1->5.5 ne sont pas triviaux.
Donc oui, encore des (très) gros paquets de 2.6.32 en prod un peu partout.
Arnaud.
Reste à surveiller les dev d'exploits pour voir s'il y a un 0day bientôt. Ça pourrait faire mal ...
Le 2 juillet 2013 23:09, Arnaud Launay asl@launay.org a écrit :
Le Tue, Jul 02, 2013 at 10:16:07PM +0200, Pierre Jaury a écrit:
Y'a encore de la prod en 2.6.32 ?
Les Debian Squeze, par exemple. Elles ne sont deprecated que depuis deux mois, et le passage de certains logiciels, par exemple php 5.3->5.4 ou mysql 5.1->5.5 ne sont pas triviaux.
Donc oui, encore des (très) gros paquets de 2.6.32 en prod un peu partout.
Arnaud.
Liste de diffusion du FRsAG http://www.frsag.org/
On 02/07/2013 23:13, Sébastien Mureau wrote:
Reste à surveiller les dev d'exploits pour voir s'il y a un 0day bientôt. Ça pourrait faire mal ...
Il me semble qu'il y a déjà le code d'un exploit là : https://www.rack911.com/poc/hemlock.c (il y a le lien sur osvdb). Je suppose qu'il suffit de changer la ligne 35 pour l'utiliser a distance.. (pas testé, ni en local d'ailleurs)
Aymeric
Bonsoir,
Plus d'informations à cette adresse : http://www.openwall.com/lists/oss-security/2013/07/02/4
"This issue does not affect upstream." C'est probablement spécifique à Red Hat avec leur habitude d'ajouter des triggers et d'autres choses.
Bonne soirée
Florent
Sans avoir cherché je dirais aussi que c'est du Red Hat specific, l'exploit PoC est out et testé avec succès en local.
Un cas de figure commun d'un Kernel 2.6.32 RH --> Proxmox pour la virtualisation.
Le bugzilla accessible au public avec patch --> https://bugzilla.redhat.com/show_bug.cgi?id=979936
A tte Le 02/07/2013 23:26, Florent CARRÉ a écrit :
Bonsoir,
Plus d'informations à cette adresse : http://www.openwall.com/lists/oss-security/2013/07/02/4
"This issue does not affect upstream." C'est probablement spécifique à Red Hat avec leur habitude d'ajouter des triggers et d'autres choses.
Bonne soirée
Florent
Liste de diffusion du FRsAG http://www.frsag.org/
Le Tue, Jul 02, 2013 at 11:26:53PM +0200, Florent CARRÉ [colundrum@gmail.com] a écrit:
Bonsoir,
Plus d'informations à cette adresse : http://www.openwall.com/lists/oss-security/2013/07/02/4
"This issue does not affect upstream." C'est probablement spécifique à Red Hat avec leur habitude d'ajouter des triggers et d'autres choses.
Sur un 2.6.32-5-xen-686 de Debian, ça finit en "failed" l'exploit mentionné.
Et tout important que ce soit, un exploit local c'est quand même plus difficile à utiliser en vrai qu'un remote, parcequ'il faut déjà réussir à avoir un accès... (sauf pour ceux qui gèrent des serveurs avec des atudiants en info dessus :o)
Bonjour,
Le 03/07/2013 09:19, Dominique Rousseau a écrit :
Et tout important que ce soit, un exploit local c'est quand même plus difficile à utiliser en vrai qu'un remote, parcequ'il faut déjà réussir à avoir un accès...
PHP est là pour régler ce petit problème de rien du tout...
Cordialement,
Christophe
Le 02/07/2013 23:09, Arnaud Launay a écrit :
Le Tue, Jul 02, 2013 at 10:16:07PM +0200, Pierre Jaury a écrit:
Y'a encore de la prod en 2.6.32 ?
Les Debian Squeze, par exemple. Elles ne sont deprecated que depuis deux mois, et le passage de certains logiciels, par exemple php 5.3->5.4 ou mysql 5.1->5.5 ne sont pas triviaux.
Donc oui, encore des (très) gros paquets de 2.6.32 en prod un peu partout.
Le fait d'upgrader ton kernel n'implique pas de dépendance sur tes logiciels. J'ai des Squeeze avec des kernel 3.8 avec php 5.3. Si tu veux rester sur les dépôts Debian tu peux regarder du côté des backports pour squeeze tu devrais avoir un kernel plus récent normalement le 3.2 de Wheezy.
Le Wed, Jul 03, 2013 at 10:50:27AM +0200, Wallace a écrit:
Donc oui, encore des (très) gros paquets de 2.6.32 en prod un peu partout.
Le fait d'upgrader ton kernel n'implique pas de dépendance sur tes logiciels.
Quel intérêt ? Ces serveurs n'ont pas de matériel récent nécessitant un noyau récent, et pour le moment le kernel de la squeeze est toujours maintenu niveau sécurité.
J'ai des Squeeze avec des kernel 3.8 avec php 5.3. Si tu veux rester sur les dépôts Debian tu peux regarder du côté des backports pour squeeze tu devrais avoir un kernel plus récent normalement le 3.2 de Wheezy.
Il y a. J'avais joué avec sur un serveur de test, ça a bien fait déconner ce qui était iscsitarget. Si c'est pour me retrouver à mettre à jour 90% du système, autant basculer en wheezy directement.
Tant que la squeeze est maintenu au niveau sécurité, on peut tranquillement pousser les clients/dev à migrer vers les "nouvelles" versions sans faire du forcing, ou se résoudre à des solutions bâtardes...
Arnaud.
Le 3 juil. 2013 à 11:38, Arnaud Launay a écrit :
Le Wed, Jul 03, 2013 at 10:50:27AM +0200, Wallace a écrit:
J'ai des Squeeze avec des kernel 3.8 avec php 5.3. Si tu veux rester sur les dépôts Debian tu peux regarder du côté des backports pour squeeze tu devrais avoir un kernel plus récent normalement le 3.2 de Wheezy.
Il y a. J'avais joué avec sur un serveur de test, ça a bien fait déconner ce qui était iscsitarget. Si c'est pour me retrouver à mettre à jour 90% du système, autant basculer en wheezy directement.
Tant que la squeeze est maintenu au niveau sécurité, on peut tranquillement pousser les clients/dev à migrer vers les "nouvelles" versions sans faire du forcing, ou se résoudre à des solutions bâtardes...
Plus généralement sur une distribution donnée, pour aller piocher dans les backports ou recompiler un logiciel ça doit se faire au cas par cas, pour un besoin précis. Ça ne doit pas se faire par principe, pour avoir toujours la dernière version. La distribution a en général été intégrée et testée avec les paquets présents sur les dépôts. Les backports c'est du best effort. Pour ma part il me reste également encore des squeeze sous 2.6.32 et je m'en porte très bien !
Cordialement Emmanuel Thierry
Le 03/07/2013 11:38, Arnaud Launay a écrit :
Le Wed, Jul 03, 2013 at 10:50:27AM +0200, Wallace a écrit:
Donc oui, encore des (très) gros paquets de 2.6.32 en prod un peu partout.
Le fait d'upgrader ton kernel n'implique pas de dépendance sur tes logiciels.
Quel intérêt ? Ces serveurs n'ont pas de matériel récent nécessitant un noyau récent, et pour le moment le kernel de la squeeze est toujours maintenu niveau sécurité.
Pour ma part rien que l'augmentation de performance en machine guest virtualisée est non négligeable, la stabilité des FS. Pour les hyperviseurs Xen un kernel 3.4 apporte bien plus de stabilité aussi par rapport à un 2.6. Je parle bien sur que dans le cas Debian.
Il ne faut pas forcément réfléchir sur matos vieux / kernel vieux. Les drivers sont souvent mis à jours pour le matériel ancien et amélioré. Je peux citer des cartes réseaux, wifi, modem gsm qui marchent bien mieux de nos jours que lorsque je les ai installé à l'époque en 2.6.
J'ai des Squeeze avec des kernel 3.8 avec php 5.3. Si tu veux rester sur les dépôts Debian tu peux regarder du côté des backports pour squeeze tu devrais avoir un kernel plus récent normalement le 3.2 de Wheezy.
Il y a. J'avais joué avec sur un serveur de test, ça a bien fait déconner ce qui était iscsitarget. Si c'est pour me retrouver à mettre à jour 90% du système, autant basculer en wheezy directement.
Encore une fois c'est à voir en fonction des archis que tu montes. iscsi + OCFS2 + multipath + drbd aucun souci sur plusieurs archis avec des kernel 3.8 + grsec J'ai aucune dépendance non plus, faut dire qu'on compile nos propres kernel aussi.
Tant que la squeeze est maintenu au niveau sécurité, on peut tranquillement pousser les clients/dev à migrer vers les "nouvelles" versions sans faire du forcing, ou se résoudre à des solutions bâtardes...
Comme on met notre kernel de façon séparé, on utilise pas les backports donc on a une solution Debian stable avec un kernel récent qui apporte lui la stabilité supplémentaire sur les FS, le drbd, ...
Bonsoir à tous,
auriez-vous des infos à ce sujet ? J'ai rien trouvé sur la liste de diffusion "debian-security-announce" et rien de plus sur les annonces web : http://www.debian.org/security/#DSAS
Je suis passé au travers ?
Alexandre
On 03/07/13 13:56, Wallace wrote:
Le 03/07/2013 11:38, Arnaud Launay a écrit :
Le Wed, Jul 03, 2013 at 10:50:27AM +0200, Wallace a écrit:
Donc oui, encore des (très) gros paquets de 2.6.32 en prod un peu partout.
Le fait d'upgrader ton kernel n'implique pas de dépendance sur tes logiciels.
Quel intérêt ? Ces serveurs n'ont pas de matériel récent nécessitant un noyau récent, et pour le moment le kernel de la squeeze est toujours maintenu niveau sécurité.
Pour ma part rien que l'augmentation de performance en machine guest virtualisée est non négligeable, la stabilité des FS. Pour les hyperviseurs Xen un kernel 3.4 apporte bien plus de stabilité aussi par rapport à un 2.6. Je parle bien sur que dans le cas Debian.
Il ne faut pas forcément réfléchir sur matos vieux / kernel vieux. Les drivers sont souvent mis à jours pour le matériel ancien et amélioré. Je peux citer des cartes réseaux, wifi, modem gsm qui marchent bien mieux de nos jours que lorsque je les ai installé à l'époque en 2.6.
J'ai des Squeeze avec des kernel 3.8 avec php 5.3. Si tu veux rester sur les dépôts Debian tu peux regarder du côté des backports pour squeeze tu devrais avoir un kernel plus récent normalement le 3.2 de Wheezy.
Il y a. J'avais joué avec sur un serveur de test, ça a bien fait déconner ce qui était iscsitarget. Si c'est pour me retrouver à mettre à jour 90% du système, autant basculer en wheezy directement.
Encore une fois c'est à voir en fonction des archis que tu montes. iscsi
- OCFS2 + multipath + drbd aucun souci sur plusieurs archis avec des
kernel 3.8 + grsec J'ai aucune dépendance non plus, faut dire qu'on compile nos propres kernel aussi.
Tant que la squeeze est maintenu au niveau sécurité, on peut tranquillement pousser les clients/dev à migrer vers les "nouvelles" versions sans faire du forcing, ou se résoudre à des solutions bâtardes...
Comme on met notre kernel de façon séparé, on utilise pas les backports donc on a une solution Debian stable avec un kernel récent qui apporte lui la stabilité supplémentaire sur les FS, le drbd, ...
Liste de diffusion du FRsAG http://www.frsag.org/
❦ 7 juillet 2013 00:57 CEST, Alexandre infos@opendoc.net :
auriez-vous des infos à ce sujet ? J'ai rien trouvé sur la liste de diffusion "debian-security-announce" et rien de plus sur les annonces web : http://www.debian.org/security/#DSAS
https://security-tracker.debian.org/tracker/CVE-2013-2224
- linux-2.6 <not-affected> (Caused by RHEL backport) - linux <not-affected> (Caused by RHEL backport)
Merci Vincent pour cette information.
On 07/07/13 09:51, Vincent Bernat wrote:
❦ 7 juillet 2013 00:57 CEST, Alexandre infos@opendoc.net :
auriez-vous des infos à ce sujet ? J'ai rien trouvé sur la liste de diffusion "debian-security-announce" et rien de plus sur les annonces web : http://www.debian.org/security/#DSAS
https://security-tracker.debian.org/tracker/CVE-2013-2224
- linux-2.6 <not-affected> (Caused by RHEL backport)
- linux <not-affected> (Caused by RHEL backport)
-
Alexandre -
Arnaud Launay -
Christophe Baegert -
Dominique Rousseau -
Emmanuel Thierry -
Florent CARRÉ -
Leslie-Alexandre DENIS - DCforDATA -
MulX (Aymeric) -
Pierre Jaury -
Sébastien Mureau -
Vincent Bernat -
Wallace