Le 13 mai, un message publié sur la liste de sécurité Debian identifiait une anomalie impactant le paquet openssl. Ce bug a été introduit par un mainteneur Debian, qui a eu la main lourde en voulant "corriger" des alertes remontées par Valgrind (un logiciel qui audite le code). Résultat des courses : le générateur de nombres aléatoires, composant critique de nombreux systèmes de chiffrements, n'est au final pas si aléatoire que ça, voire carrément prévisible.
En conséquence, tous les certificats et clefs SSL/SSH générés sur une Debian (ou dérivée) depuis 2006 l'ont été à partir d'un univers des possibles très restreint (environ 250 000 clefs, à confirmer) et présentent donc un niveau de sécurité largement inférieur à celui estimé.

Cette vulnérabilité touche Debian ainsi que toutes les distributions utilisant des paquets Debian (Ubuntu, Xandros...).

Pour prendre un exemple parlant, imaginez Securor, un fabricant de serrures qui seraient utilisées un peu partout sur la planète. Au bout de deux ans, alors que des millions de personnes ont installé des serrures pour protéger leur maison, on se rend compte qu'en fait il n'existe que 3 modèles uniques de clefs, les autres ne sont que des copies d'un des 3 modèles d'origine. Si bien qu'un voleur peut très facilement concevoir un trousseau contenant les 3 modèles de clefs, en ayant la certitude que toute serrure rencontrée pourra être ouverte avec l'une de ces clefs...

Concrètement, si vous utilisez une Debian, ou dérivée, vos VPN peuvent être cassés (adieu confidentialité des échanges), des faux certificats peuvent être signés (adieu confiance en votre système de PKI), votre serveur SSH ne filtre plus grand monde (adieu système sécurisé)...

Que faire ?

1. Mettre à jour votre distribution Debian pour installer les nouveaux paquet.
   
2. Vérifier sur tous vos systèmes qu'une clef faible n'est pas présente. Pour cela, un outil est disponible : dowkd.pl
   Si une clef faible est présente, il sera nécessaire de la générer à nouveau, avec tous les impacts que cela peut avoir (fichiers authorized_keys & know_hosts obsolètes...). Même problème pour les certificats : j'espère que personne n'a mis en place de PKI sous Debian depuis 2006, il va falloir regénérer les certificats...
   
3. lire le wiki Debian http://wiki.debian.org/SSLkeys qui vous guidera pas à pas en fonction des logiciels installés sur votre machine.

Reste à savoir quelles seront les conséquences de cette affaire : depuis 2 ans, un bug introduit par un contributeur et impactant un système critique est resté indétecté dans une des distributions les plus utilisées au monde...

NdM : lire également les articles sur Planet Debian-Fr.

Scapy est un utilitaire Open Source en Python développé par Philippe Biondi, cet outil vous permet de disséquer, de forger, de recevoir et d'émettre des paquets (et des trames) de données pour un grand nombre de protocoles que vous pourrez également décoder : DNS, DHCP, ARP, SNMP, ICMP, IP, TCP, UDP.

L'un des seuls points faibles connu à ce jour, concernant Scapy, est son manque de documentation officielle ou non, notamment francophone, permettant de le destiner à un plus large public que les experts du domaine ; partant de ce constat, le site Secuobs.com, spécialisé dans le domaine de la sécurité informatique, met à disposition de tous un document venant combler une partie de ce manque.

Vous y apprendrez notamment comment installer et configurer Scapy ainsi que les rêgles rudimentaires relatives à son utilisation (commandes basiques et avancées) et à la manipulation de paquets (et de trames) de données dont un exemple de génération de graphiques 2D/3D à partir des résultats d'un traceroute réalisé à l'aide de Scapy.

Un trou de sécurité dans BIND 8.* a encore été trouvé. Le journal "Le Monde" a été l'un des premiers à relayer cette nouvelle... Mais que faisons-nous ?

Extrait de l'article du monde:

"Par chance, le bogue a été découvert à temps et le Computer Emergency Response Team (CERT) de l'université américaine de Carnegie Mellon a publié, lundi 29 janvier, une « rustine » et vérifié que la dernière version du logiciel, Bind 9, ne présente pas ce défaut."

Mettez à jour :)

Ca ressemble à un troll mais c'est bien le titre d'un article de securityportal.

Il ne compare pas les avantages intrinsèques des deux systèmes mais mentionne plusieurs moyens de sécuriser Linux non disponible sur OpenBSD, dont les arguments sont une configuration "secure by default" (bof ...) et un code mieux audité.

- WireX : Immunix, distribution Linux orientée sécurité : SubDomain pour restreindre les fichiers accessibles à un programme, StackGuard et FormatGuard pour les bugs dus à des dépassements de buffer et les chaînes de formatage.

- openwall : piles user non exécutable, plus de liens et pipes dans /tmp

- Argus PitBull LX : Discretionary Access Control, restrictions à l'accès aux devices et aux ports (flexible, moins lourd qu'un chroot). Attention, kernels binaires seulement !

- NSA SELinux : similaire à PitBull, mais PitBull ressemble un peu à l'inspecteur gadget de la sécurité tandis que les patches de la NSA ont apparemment un design plus cohérent, j'ai l'impression que les designers ont une "big picture" du noyau, mais c'est plus délicat à paramétrer.

- LIDS : bloque certains éléments de configuration qui ne sont plus modifiable sans un accès physique à la machine.

- Medusa DS9 : plus ou moins la même chose que les précédents ?


L'auteur annonce un article "Why Linux Will Never be as Secure as OpenBSD" pour la semaine prochaine, donc il ne faut prendre le titre provocateur au pied de la lettre.

Personnellement j'ai participé au crack contest openhack sur une machine avec PitBull LX et j'ai été impressionné par sa résistance, un hacker a pu avoir un shell root avec un exploit connu mais n'a pas pour autant pu créer le fichier demandé dans la racine à cause du Discretionary Access Control.

Apparemment la sécurisation globale d'un système passe par la mise en place de tels mécanismes qui n'ont pas les limites du "Mandatory Access Control", on ne peut pas tout faire à coups de chmod.

GR-Security, le patch de sécurité pour le noyeau 2.4 qui reprend des classiques de la branche 2.2 , vient de sortir (hier) sa nouvelle version 1.8 (disponible pour 2.4.9 et 2.4.10).

Nouveautés: update PaX (http://pageexec.virtualave.net) code, anti-fork bombing code, pas mal d'updates pour l'ACL, ainsi que du bugfix.

(Une modif de dernière minute sur la release du 24-09 ayant été faite, il vous est conseillé de repomper la dernière du 25)

On parle beaucoup de sécurité, mais combien d'entre nous peuvent prétendre d'avoir un système correctement sécurisée.
Le développement de "distributions" permettant de mettre en place un firewall facilement accessible à tous et ne nécessitant pas des connaissances trop pointues dans ce domaine est en plein renouveau.
On a souvent parlé de la distrib Smoothwall, permettant de recycler son vieux 486, mais une autre alternative existe Startup Linux, qui a mon goût est plus complet et inclus le minimun pour celui qui veut faire le maximun s'en pour autant être un expert. Bien sûr un expert préfèrera toujours faire sa propre sécurité avec son propre firewall et sa DMZ, mais ce genre de produit s'adresse aux débutants soucieux de se sécuriser un minimun tout en adoptant un produit fiable et gratuit, comme aux utilisateurs plus avancés.
Pour pouvoir se consacrer tranquillement à autre chose, et se préparer plus sereinement à une configuration personnelle.
Vive l'alternative.

Annoncé aujourd'hui sur la mailing list de gnupg-users, la création d'une mailing list keysignings@lists.alt.org permettant à tous ceux qui ont des clés GPG d'annoncer leur passage dans une ville à l'avance, de sorte à pouvoir utiliser un voyage pour rencontrer des gens et signer leurs clés. Autrement dit, organiser un first d'échange de signature, à la volée, n'importe ou et n'importe quand.

Une défaillance dans le binaire lprm (utilitaire pour effacer des travaux partis à l'impression) de OpenBSD rend la possiblité d'exploiter le système avec les privilèges du propriétaire de lprm.

Cependant, depuis OpenBSD 3.2, cet utilitaire appartient à l'utilisateur daemon et non root ce qui limite les possibilités.
Des correctifs sont disponibles.

Challenge Securitech est un concours de sécurité informatique qui a eu lieu du 10 avril au 1er mai.
Le concours vient donc de se terminer ce week-end. Dans le cadre du challenge est organisée une conférence le vendredi 7 mai 2004 à 17h dans le 5ème arrondissement de Paris.
Seront notamment présents, Kostya Kortchinsky, responsable du CERT RENATER et Nicolas Brulez, The Armadillo Software Protection System :
Kostya Kortchinsky animera une présentation sur les shellcode ~crosoft.
Nicolas Brulez présentera quant à lui les techniques de reverse engineering.

Les solutions des 20 niveaux du Challenge seront également débattues.