Archives mensuelles : mai 2008

A propos de la fameuse faille OpenSSL sur Debian et dérivés

L’histoire en quelques mots

Bon, je poste un peu après tout le monde sur le sujet. Mais c’est histoire de faire part de 2/3 remarques. A voir les news postées un peu partout, j’ai l’impression de revivre la naissance de « Blaster » sous Windows : grande ampleur alors que la correction existait et beaucoup découvrent/découvraient ça tardivement sans trop savoir quoi faire.
Bon ici, il ne s’agit que de rectifier avant qu’une faille soit exploitable. Mais c’est extrêmement préoccupant.
Et le pire, c’est que contrairement à beaucoup de failles, le problème réside dans les « clefs de cryptage » que vous utilisez (qui vous sont propres), pas dans l’outil en lui-même. Donc appliquer les patchs constitue seulement 1% de la solution. (dans le cas où vos clefs ont été générées, disons, entre hier et y’a 2 ans… c’est large)

Point de départ de l’information

Si vous découvrez seulement maintenant le sujet et que vous gérez des Debian ou Ubuntu ou dérivés, c’est grave, lisez vite les « security advisory » de openssl et de openssh publié le lendemain. Ce sont les seules sources fiables, comme point de départ.
Si ça vous gonfle car c’est en anglais, parce-que personne n’en voudrait à votre pseudo-serveur etc, alors arrêtez tout de suite de « gérer » un serveur…
Le wiki de Debian résume bien tous les services qui peuvent être impactés et donnent les opérations à faire. A commencer par OpenSSH (tout le monde l’a celui-là)

Donc, pour cette fois, et pour les suivantes, faites ceci :

Pour bien réagir la prochaine fois :

Inscrivez-vous sur la mailing-list de securité Debian

Inscrivez-vous soit par l’interface web, soit en envoyant un mail à debian-security-announce-REQUEST@lists.debian.org avec sujet subscribe et en confirmant une fois le 1er de retour reçu).
Optez pour celle appelée « debian-security-announce », pas nécessairement « debian-security » qui est plutôt une chat-room non modérée 😉
=> Ainsi, vous serez au courant au bon moment avec les bonnes infos, plutôt que des « on dit » incomplets sur des forums.
Si vous n’êtes pas en Debian, ça vaut quand même. Il doit y avoir l’équivalent sur Ubuntu et autres dérivés.

Lisez les alertes à tête reposée et faites ce qui est demandé

Par exemple, dans celle d’OpenSSL dit notamment une toute petite phrase : « We recommend that you upgrade your openssl package and subsequently regenerate any cryptographic material, as outlined above. »
=> Cette toute petite phrase veut simplement dire qu’il faut regénérer TOUT ce qui a trait à la crypto. Donc tous vos certificats pour vos protocoles sécurisés, notamment SSH, HTTPS, POP3S, IMAPS, SSMTP etc. Sans parler des known_hosts et authorized_keys. En gros, si vous gérez un paquet de serveurs, ça va juste vous pourrir un bon paquet d’heures. Mais c’est obligatoire.

Le mot de la fin

Voilou, c’était histoire de clarifier la situation vu ce qu’on peut lire comme info incomplète sur cette faille. Le classique "apt-get update ; apt-get upgrade" du matin ne suffit pas !
J’ai eu envie de faire cet article quand je pense aux hébergeurs qui proposent des serveurs à pas cher, avec environ 97% d’admin archi-débutant-pas-sérieux. Je me ferais du souci à leur place. Surtout si un exploit est révélé !
Faites que le mien ne bloque pas le trafic SSH en cas d’exploit révélé (si si, mon hébergeur l’a proposé, arg !)…. ce serait un bordel sans nom.

La PS3 lit trop vite ? O_o

Récemment, j’ai encodé tout un tas de DVD en « MP4 » via Nero Recode ou Handbrake. Après compression, je les lis d’abord sur un PC avec VLC avant de les stocker sur un NAS pour les lire sur la PS3. Pas de problème jusque là, tout allait bien. Sauf que…

Puis en regardant un des films que je connaissais déjà bien, j’ai trouvé que le son était accéléré, sensiblement. Et que le chrono allait un peu vite aussi (lors de la lecture sur la PS3).
Sachant que je n’ai rien changé côté compression, j’ai rééencodé. Même topo… Continuer la lecture

TortoiseCVS, Truecrypt et clef USB…

J’utilise TortoiseCVS pour accéder à un dépôt un peu sensible. Afin de le protéger sur mon ordi portable (en cas de vol), j’ai préféré le stocker sur une clef USB utilisant un container Truecrypt utilisant un bon cryptage et mot de passe long comme le bras.

Manque de bol, TortoiseCVS ne voulait pas me faire de checkout sur une clef USB ou sur un « container Truecrypt », vu aussi comme une clef USB, un « périphérique amovible ».

Pour régler ce problème, il faut penser à décocher la case « Mount volumes as removable media » dans les options de Truecrypt. C’est tout con, mais j’ai perdu une heure…

La contrepartie est expliquée dans les FAQ de Truecrypt. Rien de violent à vrai dire :

Q: What will change when I enable the option ‘Mount volumes as removable media’?

A: You can enable this option, for example, to prevent Windows from automatically creating the ‘Recycled’ and/or the ‘System Volume Information’ folders on TrueCrypt volumes (in Windows, these folders are used by the Recycle Bin and System Restore facilities). However, there are some disadvantages. For example, when you enable this option, the ‘Computer’ (or ‘My Computer’) list will not show free space on the volume (note that this is a Windows limitation, not a bug in TrueCrypt).

Ce qui est pénible, c’est que c’est probablement une nouvelle version de TortoiseCVS qui m’a apporté ce problème (je ne trouve pas que ce soit une « feature » que de rejeter les clefs USB comme ça sans rien dire, c’est plutôt un bug…). Je vais éplucher un peu les releases notes et forums à ce sujet.