Plop et tout d’abord merci à tous et à toutes pour vos messages de soutien, suite au dernier édito. J’y reviendrai dans un autre billet. Sachez quand même que cela m’a (très sincèrement) fait chaud au cœur et surtout que la personne concernée, à savoir ma mère, m’a sommé de ne pas vous laisser sans rien. Je me suis fait engueuler (copieux) quand elle a su que je ne publiais plus rien et m’a sommé de m’y remettre fissa fissa (selon ces termes). Oui, elle est plutôt Funky ma maman. Et même si elle ne pèse que 40 kilos, il ne vaut mieux pas s’y frotter :)
Alors je reprends un peu le mulot pour vous parler de Shellshock, qui si vous n’avez pas suivi l’histoire est une faille (découverte par Stéphane Chazelas) permettant à un utilisateur malveillant de compromettre et de prendre le contrôle de systèmes Linux, BSD et Mac OS X, utilisant Bash comme interpréteur de commande. Je ne vais pas tenter de la détailler ici car je ne suis pas assez calé, mais si ça vous intéresse les gens de linuxfr.org ont publié un article très bien détaillé, comme eux seuls savent le faire. Si vous le souhaitez par contre, voici deux tests rapides vous permettant de vérifier l’intégrité de votre système, afin de savoir s’il est vulnérable ou non.
Test 1 :
Le premier test consiste a entrer la ligne de commande suivante :
x='() { :;}; echo vulnerable' bash -c "echo ceci est un test"
Si vous obtenez le retour suivant, c’est que tout va bien :
ceci est un test
Si vous voyez celui-ci en revanche, c’est que votre système est faillible :
vulnerable ceci est un test
Test 2 :
Le second test (qui pour la petite histoire vise à pallier l’insuffisance d’un premier correctif) consiste à entrer la commande suivante :
cd /tmp; rm -f echo; env 'x=() { (a)=>\' bash -c "echo date"; cat echo
Si tout va bien vous devriez obtenir le message suivant :
cat: echo: Aucun fichier ou dossier de ce type
Conclusion :
Dans les faits vous ne devriez pas avoir de soucis à vous faire si vous effectuez régulièrement vos mises à jour, ce qui nous ne le répéterons jamais assez souvent est primordial. Si ce n’est pas encore fait il est grand temps de faire chauffer vos terminaux et d’effectuer un update.
Amusez-vous bien.
Plop
RAS : ma wheezy a bien fait ses mises à jour
Moo
1 [22:38:14] adriencl@superlinux: ~ $ x='() { :;}; echo vulnerable’ bash -c « echo ceci est un test »
ceci est un test
2 [22:38:18] adriencl@superlinux: ~ $ cd /tmp; rm -f echo; env ‘x=() { (a)=>\’ bash -c « echo date »; cat echo
date
cat: echo: Aucun fichier ou dossier de ce type
3 [22:38:26] adriencl@superlinux: /tmp $ bash –version
GNU bash, version 4.2.50(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
Licence GPLv3+ : GNU GPL version 3 ou ultérieure
Ceci est un logiciel libre ; vous être libre de le modifier et de le redistribuer.
Aucune garantie n’est fournie, dans la mesure de ce que la loi autorise.
Tiens ?!! Je ne savais pas que tu étais de strass !!!
Ubuntu 14.04, 2 tests négatifs, ouf.
La deuxième méthode vise à vérifier que le shell ne peut qu’injecter des commandes root au sein du répertoire /tmp si j’ai bien compris (et la lecture du 2e code me le confirme).
Du coup je m’interrogeais sur le fait de savoir, si cette correction de bug pour le répertoire /tmp était vraiment critique ? Que peut-on faire avec ? Du man-in-the-middle ? Du bufferOverflow ? Du rootkits ?
Tu peux lire l’article Linuxfr et les liens associés pour tout savoir. Je vais être franc, je n’ai pas tout calé hi hi :)
Le titre est mal choisi. Ça ne permet pas de verifier «l’integrité» du système, mais uniquement de savoir si on est vulnérable actuellement.
Si vous avez un environnement de production qui a été vulnérable, je vous conseille plutôt de reprendre la backup pré-shellshock et de la comparer à l’état actuel de vos fichiers. Notamment les fichiers de configuration. Et ça, c’est plus ou moins le minimum.
Tu as raison. Je me suis rendu compte après coup que le titre était bancal (pour ne pas dire à la ramasse), mais bon, c’était déjà parti.
Disons qu’avec un ‘Bash bug’ dans le titre ça t’aurait aidé en terme de référencement.
En fait (très sincèrement) je ne me suis jamais vraiment soucié du référencement pour être franc.
Tiens ca me fait penser à une question :
Existe-t-il sous debian (et ses dérivées) une commande que l’on pourrait « cronner » afin de recevoir chaque jour ou chaque semaine les mises à jour disponibles par email ?
Je m’auto-répond !
Il y a donc le paquet « unattended-upgrades » qui procède aux mises à jour automatiquement (sans action), et de façon paramétrable (sécurité uniquement, ou toutes les mises à jour),
Et le paquet « apticron » qui notifie des mises à jour disponibles par email !
Magnifique !
Merci, ça peut être utile ;)
Moi je suis sur Manjaro KDE c’est ok pour moi :)
@SALAMANDAR : Certes, c’est le genre de failles que les package mainteners mettent direct dans leur TODO en position #0 :)
Ce qui est gênant dans ce genre de failles, c’est qu’il y a des centaines de serveurs de prod en entreprise qui ne sont pas mis à jour « pour des raisons de stabilité »… il doit y avoir tant de serveur qui traînent encore HeartBleed ou ShellShock… Enfin, ça sera jamais pire que sous Windows x)
Tu as tout à fait raison. Je pensais d’ailleurs à Heartbleed… La plupart des serveurs ont forcément été mis à jour juste pour ça, c’est tellement sensible que…
En tout cas j’imagine que ce sera encore le cas pour ShellShock. Perso mon raspi n’y est pas sensible ^^
Un serveur web est vraiment faillible quand il s’agit de Bash ? Comment peut-on faire exécuter quelque chose à Bash par http ? :p
Et si oui, la fonction définie a « quels droits » ? (définie dans l’environnement de quel utilisateur ?)
Aaaaaaaaaaaaaaaaah ça explique la mise à jour de Bash il y a quelques jours sous Manjaro/Arch ?
Encore beaucoup de courage à ta famille et ta mère !
Merci. J’ai tiqué aussi quand j’ai vu passer la maj.