Historiquement, l'un des gros points noirs d'ubuntu était son petit coté "expérimental" sur le choix des composants, des versions etc. Cela aboutissait généralement à un système "pas totalement stable", qui avait la fâcheuse habitude de se crasher en beauté lors des mise à jour.

Oui, j'exagère un peu. Mais en ce qui me concerne, le taux de réussite d'un changement de version avait toujours avoisiné les cinquante pour cents, avec parfois de grosses surprises à la clef.

Depuis la sortie de la version 14.04, j'ai du mettre à jour au moins 5 ou 6 machines. Et le résultat est bluffant. Zéros problèmes. Que ce soit depuis la version 12.04 (LTS), ou depuis la 13.10, toutes les mises à jours se sont parfaitement déroulées, y compris sur un système bancal avant la mise à jour (gestionnaire de fenêtre à moitié HS).

Non seulement la mise à jour se passe bien, mais tous les petits changements effectués vont dans le bon sens. Choix des menus en haut ou dans la barre de titres des fenêtres, possibilité de désactiver la recherche en ligne en un clic etc. J'ai aussi constaté une nette amélioration du driver wifi de mon chipset, avec un temps de latence divisé par 100 ! (oui, j'avais vraiment un soucis avant, ce qui provoquait parfois des ralentissements lors de la navigation)

Bien sur, ce n'est pas parce que chez moi tout fonctionne qu'il faut se lancer les yeux fermés. Faite une sauvegarde totale de votre système, en bootant sur un système "live" et en utilisant fsarchiver. Mais j'ai bien l'impression qu'il y aura beaucoup moins de problème avec cette version 14.04 qu'avec les précédentes.

Si ça se confirme, well done Canonical !

Ayant un certain nombre de disques durs chez moi, je suis parfois confronté à ce genre de choses :

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.

Et ça c'est quand on a de la chance, sinon ça préviens pas...

Voici les deux sites permettant de savoir si son disque est toujours sous garantie ou pas, en fonction des constructeurs restants suite aux différents rachats :

Western digital (et Hitashi.. et IBM...) :

http://www.hgst.com/portal/site/en/support/warranty/

Seagate (et Samsung)

http://support.seagate.com/customer/en-US/warranty_validation.jsp?form=0

Toshiba (et Fujitsu)

Si je résume bien ce qui est indiqué ici, en cas de panne d'un disque dur Toshiba, c'est à vous de vous démerder avec le vendeur. Toshiba lui s'en bat les couilles. (Ce n'est pas forcément indiqué comme ça, mais c'est l'idée).

Je note ça ici car ça m'évitera de refaire la même recherche à chaque fois...

Vous avez écrit un script shell et aimeriez vérifier qu'il ne contient pas trop d'erreurs (syntaxiques ET sémantique) ? Alors allez vite faire un tour sur www.shellcheck.net . Cet outil en ligne (ou hors ligne si vous décidez de le télécharger) donne des résultats assez bluffants. Il m'a immédiatement trouvé un bug dans kclean ! Plus précisément, j'avais oublié un $ devant un nom de variable, qui n'était donc pas interprétée. Un problème heureusement sans conséquences sur les suppressions et tout le travail "réel" du script.

kclean passe donc en version 3.5. Une version qui, en plus de la correction nécessaire, intègre aussi le calcul de l'espace disque théoriquement libéré après suppression des noyaux. Une information qui apparaitra, que vous l'utilisiez en mode texte ou en mode graphique.

Un grand merci à Vinny qui a fait passer l'info sur le forum ubuntu-fr.

Commençons par HES. Cette convention de très haut niveau a rassemblée environ 200 personnes venues écouter des chercheurs en sécurité triés sur le volet. Ils présentaient leurs recherches et les exploits développés suite aux failles découvertes. Je n'aurai finalement assisté qu'a deux de ces conférences, mais elles étaient passionnantes. Voila donc un petit résumé de ce que j'ai entendu sur place.

Open Source Monitoring Security Issues

Il semblait logique de se pencher sur la sécurité des outils de supervision :

• Le serveur à souvent accès à toutes les machines, sur tous les réseaux (DMZs etc)
• Il est positionné "profondément" dans l'architecture, dans un réseau de confiance
• Il contient énormément de données (logs, traps snmp etc)
• Des agents de supervision sont souvent installés sur tous les équipements

Volontairement, ces deux chercheurs ont laissés de coté les solutions commerciales, ainsi que les fonctions forcément non sécurisées (exécution à distance etc), et les plugins qui ne sont pas intégrés par défaut avec le logiciel. Ils ont décortiqués quatre solutions : Cacti, Nagios, check_mk et Icinga. Ces études n'ont étés faites qu'avec les paramètres par défaut, sur des configurations réalistes.

Vous vous en doutez, ils ont trouvés des problèmes critiques dans tous ces logiciels (XSS etc, la liste est longue). Résultats : De magnifiques démonstrations, des shells en pagaille si l'admin vient à cliquer sur une url piégée. Plus rigolo, en rootant une des machines supervisée, il est possible de utiliser comme proxy pour remonter jusqu'au serveur.

Mais Le clou du spectacle était de parvenir à faire la même chose sans devoir "hacker" la machine supervisée. Une simple tentative de connexion ssh peut en effet suffire à corrompre la solution. Pour cela, on suppose que logwatch est installé. En lançant une connexion ssh avec des chaine de caractère spécifique (nom de l'utilisateur etc), on arrive a hacker le serveur de supervision, qui se chope l'exploit lors de la remonté des logs via logwatch. La grande classe non ?

Bien sur, toutes ces failles ont étés expliquées aux développeurs de chacune des solutions. Le temps moyen de correction est très bon puisqu'il n'a fallu en moyenne que six jours pour que les problèmes soit référencés (CVE...) et corrigés. Malheureusement il y a de grosses différences entre les équipes. Les développeurs de cacti auraient été très mauvais (limite pas de réponses). Au contraire les chercheurs félicitent les développeurs d'Icinga pour l'ensemble de leurs actions (Déjà penser à remercier...) Bref, en résumé, il faut vraiment éviter Cacti et Check_mk.

Lors des questions/réponses, j'ai demandé si ils avaient eu le temps de regarder Zabbix. La réponse est non. J'espère que lui aussi fera l'objet d'un audit poussé prochainement, en espérant que eux aussi traitent ce genre de choses serieusement

Extracting public keys from embeddeb devices

Durant le premier quart d'heure, j'ai été vite largué, avec la peur de ne rien capter de toute la présentation. Il s'agissait en effet d'un "rappel" sur les bases mathématiques du chiffrement asymétrique (clef publique/privée). La conclusion de cette introduction était qu'il est mathématiquement possible de calculer la clef publique utilisée pour une communication à partir de deux messages signés (signature effectué bien sur à partir de la clef privée). Je suis déjà assez content d'avoir compris la conclusion, ne me demandez pas de vous expliquer comment.

Mais vous vous posez surement la question... Quel est l’intérêt de trouver une clef qui est "publique" par définition ? L'idée c'est que, dans la pratique, la clef publique ne l'est pas toujours : Équipement de type "boite noire", système embarqué ou il n'est pas possible d'extraire les clefs etc). L’intérêt est d'auditer des systèmes qui utiliseraient des clefs trop faibles. (D'autres exemples ont étés donnés mais, la encore, je n'ai pas tout compris).

Nous avons alors droit à une petite démonstration sympathique avec deux fichiers textes en entré. Deux mails signés, récupérés sur une mailing de kernel.org. En quelques minutes, un script python associé à une librairie mathématique calcule la clef publique associée.

La suite sera beaucoup plus intéressante. On apprend en effet que les systèmes d'ouvertures des immeubles en France, le système Vigik, utiliserai justement des clefs trop faibles. Vous voyez de quoi on parle ? La porte de votre immeuble qui s'ouvre quand vous placez votre "token" devant le machin noir à coté de la sonnette... Le contenu des cartes (token) est maintenant totalement connu. Le firmware des lecteurs à été dumpé etc. Or, la clef RSA utilisée ne peut pas avoir une taille supérieur à 1024 bits, ce qui aujourd'hui est un peu faible. A moins de rapidement remplacer l'ensemble des lecteurs (environ un million en France, à 100 euros pièces...), il est probable que le système sera complétement cassé dans quelques années. Ce qui donnerait lieu à des petites choses rigolotes comme des applications pour smartphone permettant de se faire passer pour le postier (ou mieux, un employé EDF) et donc de rentrer dans n'importe quel immeuble juste avec son téléphone...

Notez que les gens qui spamment vos boites aux lettres sont identifiés comme "autre service postaux". Ils ont accès à l'immeuble même le dimanche, ce qui n'est pas le cas du facteur ordinaire ! Notez aussi qu'un pass "perdu" n'est utilisable que 24 heures, après quoi il faut charger une nouvelle clef à l’intérieur.

Hacker space fest

En parallèle d'HES, le HSF était un espace en accès libre, organisé en atelier. Des "hackers fous" y pressentaient leurs travaux dans des domaines aussi variés que la fermentation, le textile, la musique ou l'analyse des ondes cérébrales. D'autres se rassemblaient autour d'une "chiffro-fête" afin de s'échanger leurs clefs publiques, ou d'expliquer aux visiteurs curieux la signification de tout ça :)

Une visiteuse test le dispositif de NeuroHack :

Des présentations plus classiques ont aussi eu lieu, concernant chacun de ces sujets. Je n'ai malheureusement pas pu rester assez longtemps pour pouvoir entrer dans le détail mais, concernant l’association "informatique/électronique" avec le textile, franchement il y avait du lourd. Je ne pensai pas qu'on pouvait faire tout ça avec du tissu. Des poches qui faisaient office de condensateur, des tricots dont l’étirement était mesurable en faisait passer un courant électrique à l’intérieur, des fibres optiques tissées etc. Tout cela était réalisé de façon très artisanale mais ça fonctionnait parfaitement. Il ne reste plus qu'a trouver une utilité industrielle concrète à toutes ces bonnes idées.

Pour l’anecdote, ce HSF m'aura permis de (re)croiser Genma, lui aussi bi-classé geek/otaku et venu pour la chiffro-fête (crypto-party). J'ai aussi eu le plaisir de rencontrer Aeris, qui m'a appris pas mal de choses sur TAO et leurs joujoux. Des informations sont à récupérer ici. Vous je ne sais pas mais moi je ne regarderai plus jamais mes connecteurs USB de la même façon...

Merci Aeris ! (Pour ça et pour ne pas t'être trop foutu de ma gueule pendant ma prez sur le chiffrement ;) A une prochaine j'espère.

La cité des sciences et de l'industrie, porte de la villette, accueille en ce moment les conférence d'Hackito Ergo Sum. En parallèle, et au même endroit, se tiens également le HSF, qui lui la bonne idée d’être 100% gratuit.

Si vous ne savez pas quoi faire demain pourquoi pas venir jeter un œil ? J'aurai normalement le plaisir, samedi à 11h, de faire une petite presentation basique sur le chiffrement.

Bien que ce soit sans prétentions, je ne résiste pas à la capture d'écran, parce que bon... Ca le fait quand même ! :)