NewPKI est une nouvelle solution de PKI libre (NdM: licence propre au logicel, libre, copyleftée, et, semble-t'il compatible GPL) développée autour d'OpenSSL.
Le serveur et le client peuvent être installé sous GNU/Linux ou sous Windows (9x comme NT/2000).
Le serveur s'appuie sur une base de données MySQL pour le stockage des données, ce qui permet une grande flexibilité.
Voici quelques fonctionnalités supportées par NewPKI :
- Gestion de multiples AC dans un seul serveur.
- Publication dune demande de certificat depuis un PKCS10.
- Publication dune demande de certificat en saisissant les champs du DN.
- Gestion en PKCS12 des clés privées des certificats.
- Gestion des SmartCards.
- Recherche dans un LDAP et publication du certificat.
- Recherche de certificats et des demandes.
- OCSP responder.
- Possibilité d'utilisation de modules hard pour stocker les clés d'AC.
- Toutes les fonctionnalités courantes pour une PKI (révocation, création de CRLs, etc.).
Le filtrage de mail avec Perl
Il y aplusieurs manières de filtrer vos mails avec Perl.
Les deux méthodes les plus populaires et les plus inétressantes sont d'utiliser:
- PerlMX
- Mail::Audit
Un article sur Perl.com rédigé par Michael Stevens prend le temps de nous présenter ces deux solutions et nous livre son avis sur la question.
NdR: Quelques liens de plus ça ne fait pas de mal :)
Les deux méthodes les plus populaires et les plus inétressantes sont d'utiliser:
- PerlMX
- Mail::Audit
Un article sur Perl.com rédigé par Michael Stevens prend le temps de nous présenter ces deux solutions et nous livre son avis sur la question.
NdR: Quelques liens de plus ça ne fait pas de mal :)
Nouvelle faille OpenBSD
Une nouvelle faille a été découverte dans le noyau de OpenBSD.
Un oubli de verification dans les appels systemes select et poll permet à un attaquant d'ecrire sur la mémoire du noyau, et d'éxecuter des instructions arbitraires.
Les utilisateurs locaux du systeme ont donc la possibilité de passer root sur la machine.
Des patchs sont disponibles pour les version 3.0 et 3.1 d'OpenBSD.
Un oubli de verification dans les appels systemes select et poll permet à un attaquant d'ecrire sur la mémoire du noyau, et d'éxecuter des instructions arbitraires.
Les utilisateurs locaux du systeme ont donc la possibilité de passer root sur la machine.
Des patchs sont disponibles pour les version 3.0 et 3.1 d'OpenBSD.
Nouveaux packages pour slackware 8.1
Plusieurs problèmes de sécurité ont été réglés sur différents packages de la Slack 8.1.
On note entre autres une correction de "buffer overflow" dans la glibc, d'un bug permettant d'escalader des privilèges dans Apache, un passage à OpenSSL 0.9.6e et une recompilation d'openSSH en conséquence.
ND(partial)M : Slack r3lWz
On note entre autres une correction de "buffer overflow" dans la glibc, d'un bug permettant d'escalader des privilèges dans Apache, un passage à OpenSSL 0.9.6e et une recompilation d'openSSH en conséquence.
ND(partial)M : Slack r3lWz
Cheval de troie dans OpenSSH
D'après un mail sur la liste de freebsd-security, le tarball de la dernier version d'openssh portable (openssh-3.4-p1) contient un shell code dans openbsd-compat/bf-test.c, qui sera lancé via Makefile.in si on fait un make.
Vous pouvez comparez avec un miroir :
ftp.openbsd.org (infecté) :
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz
ftp.lip6.org (non infecté):
ftp://ftp.lip6.fr/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz
Vous pouvez comparez avec un miroir :
ftp.openbsd.org (infecté) :
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz
ftp.lip6.org (non infecté):
ftp://ftp.lip6.fr/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz
Failles de sécurité dans openssl
Des failles de sécurité dans openssl 0.9.6d ou inférieur ou 0.9.7-beta2 ou inférieur ont été découvertes par A.L. Digital Ltd et The Bunker lors d'un audit de securité. Pas moins de 4 vulnerabilités sont exploitables.
compte-rendu d'un pot de miel avec OpenBSD 3.0
Un compte-rendu et l'analyse d'une mise en place d'un pot de miel (honeypot) avec OpenBSD 3.0 vient d'etre publié. L'auteur l'a rédigé en une trentaine d'heure et a laissé ouverte la porte qui permet d'exploiter "la seule faille distante découverte en 6 ans" d'OpenBSD.
Un jeune pirate s'est retrouvé "collé" dedans comme l'indique le rapport. Mais là où cela se complique, c'est que l'anonymat du pirate a été très mal conservé dans le rapport (notamment à cause de captures d'écran maladroites).
La nouvelle a été commentée sur /. et les contributeurs se sont fait une joie de divulguer nom, prénom, photos, addresse (avec plan et photos de la maison), numéro de téléphone, contacts ICQ/AIM, addresses emails, posts sur alt.hacking du dénommé omegakidd. Quelqu'un lui a même téléphoné pour lui demander s'il était bien au courant d'être le "crétin le plus connu de slashdot".
En effet, on se demande qui cela peut bien être...
Un jeune pirate s'est retrouvé "collé" dedans comme l'indique le rapport. Mais là où cela se complique, c'est que l'anonymat du pirate a été très mal conservé dans le rapport (notamment à cause de captures d'écran maladroites).
La nouvelle a été commentée sur /. et les contributeurs se sont fait une joie de divulguer nom, prénom, photos, addresse (avec plan et photos de la maison), numéro de téléphone, contacts ICQ/AIM, addresses emails, posts sur alt.hacking du dénommé omegakidd. Quelqu'un lui a même téléphoné pour lui demander s'il était bien au courant d'être le "crétin le plus connu de slashdot".
En effet, on se demande qui cela peut bien être...
Apache : Mettez à jour !
La société StrongHoldNet vient de faire une étude sur la sécurité des serveurs français utilisant Apache (tous systèmes d'exploitations confondus).
Il en ressort la chose suivante:
- 20.5 % d'entre eux (dont linuxfr.org fait partie :-) utilisent une version non vulnérable d'Apache (>= 1.3.26 or >= 2.0.39),
- 23.2 % d'entre eux utilisent une version antérieure patchée,
- 56.3 % d'entre eux sont vulnérables (soit 23 % du total des serveurs
web français).
Pour le moment, des exploits ont été publiés seulement pour OpenBSD, NetBSD et FreeBSD (d'ailleurs le vers "Scalper" exploite justement la vulnérabilité sous FreeBSD); pas encore d'exploit largement diffusé pour Linux, mais GOBBLES (auteur de l'exploit pour les *BSD) prétend que c'est possible.
Moralité : Mettez tous vos Apache à jour avant que l'exploit pour Linux soit connu. Un vers "Nimda-like" qui infecte des miliers de machines sous Linux serait du plus mauvais effet pour la réputation du système...
Il en ressort la chose suivante:
- 20.5 % d'entre eux (dont linuxfr.org fait partie :-) utilisent une version non vulnérable d'Apache (>= 1.3.26 or >= 2.0.39),
- 23.2 % d'entre eux utilisent une version antérieure patchée,
- 56.3 % d'entre eux sont vulnérables (soit 23 % du total des serveurs
web français).
Pour le moment, des exploits ont été publiés seulement pour OpenBSD, NetBSD et FreeBSD (d'ailleurs le vers "Scalper" exploite justement la vulnérabilité sous FreeBSD); pas encore d'exploit largement diffusé pour Linux, mais GOBBLES (auteur de l'exploit pour les *BSD) prétend que c'est possible.
Moralité : Mettez tous vos Apache à jour avant que l'exploit pour Linux soit connu. Un vers "Nimda-like" qui infecte des miliers de machines sous Linux serait du plus mauvais effet pour la réputation du système...
Une backdoor dans un package sur ftp.bitchx.org
Hank Leininger indique sur Securityfocus que le package ircii-pana-1.0c19.tar.gz qui était téléchargeable jusqu'au 1 Juillet, sur ftp.bitchx.org, était vérolé par une backdoor. Le script tente une connection à l'extérieur une fois par heure.
Le même package téléchargeable à partir de ftp.irc.org est sain.
Le code ajouté au package ircii-pana-1.0c19.tar.gz initial est indiqué dans le post de Hank Leininger.
Le problème devient très génant lorsque Hank Leininger s'apperçoit qu'il y a plusieurs copies de ce package sur ftp.bitchx.org (au moins deux), et que certains téléchargement fournissent une version vérolée et pas d'autre. Les utilisateurs qui se connectent avec des modem-cables ou DSL semblent recevoir les versions vérolés, alors que les utilisateurs ayant des connections moins rapide reçoivent la version saine.
De plus, rapatrier le package un par client ftp peut livrer une copie saine alors que Lynx récupère une copie vérolée.
Hank Leininger en arrive à la conclusion que ftp.bitchx.org a surement été rootkité, et qu'il faut donc se méfier de tout package en provenance de ce serveur ou de ses mirroirs.
Les développeurs du site seraient en train de chercher le trou de sécurité dans leur système.
Au moment ou je poste cette news, le site bitchx.org semble fermé.
Cette news est passée sur unixtech.be mais avec le titre bizarre "Apres la backdoor d'irssi, voici celle de BitchX", et juste le lien sur securityfocus.
Le même package téléchargeable à partir de ftp.irc.org est sain.
Le code ajouté au package ircii-pana-1.0c19.tar.gz initial est indiqué dans le post de Hank Leininger.
Le problème devient très génant lorsque Hank Leininger s'apperçoit qu'il y a plusieurs copies de ce package sur ftp.bitchx.org (au moins deux), et que certains téléchargement fournissent une version vérolée et pas d'autre. Les utilisateurs qui se connectent avec des modem-cables ou DSL semblent recevoir les versions vérolés, alors que les utilisateurs ayant des connections moins rapide reçoivent la version saine.
De plus, rapatrier le package un par client ftp peut livrer une copie saine alors que Lynx récupère une copie vérolée.
Hank Leininger en arrive à la conclusion que ftp.bitchx.org a surement été rootkité, et qu'il faut donc se méfier de tout package en provenance de ce serveur ou de ses mirroirs.
Les développeurs du site seraient en train de chercher le trou de sécurité dans leur système.
Au moment ou je poste cette news, le site bitchx.org semble fermé.
Cette news est passée sur unixtech.be mais avec le titre bizarre "Apres la backdoor d'irssi, voici celle de BitchX", et juste le lien sur securityfocus.
news sur les problèmes de OpenSSH
La grande nouvelle est la mise à disposition de l'exploit de Gobbles, qui après s'etre illustré avec son exploit pour Apache remet ca avec OpenSSH.
L'avantage reste que maintenant on peut tester tous nos petits Linux et vérifier s'ils sont ou non vulnérables. J'ai donc pu confirmer que les packages ssh de Debian avant mise à jour n'etaient pas vulnérable ;-)
(par contre l'exploit marche tout à fait sur un OpenBSD 3.1 fraichement installé mais pas sur un 3.1-current).
Sinon l'équipe de OpenSSH a releasé juste avant l'exploit une mise à jour de l'advisory et explique notamment dedans pourquoi ils ont annoncé la faille de cette façon (en donnant le moins de détails possible, en faisant croire que toutes les versions de OpenSSH étaient vulnérables, etc. ...).
L'avantage reste que maintenant on peut tester tous nos petits Linux et vérifier s'ils sont ou non vulnérables. J'ai donc pu confirmer que les packages ssh de Debian avant mise à jour n'etaient pas vulnérable ;-)
(par contre l'exploit marche tout à fait sur un OpenBSD 3.1 fraichement installé mais pas sur un 3.1-current).
Sinon l'équipe de OpenSSH a releasé juste avant l'exploit une mise à jour de l'advisory et explique notamment dedans pourquoi ils ont annoncé la faille de cette façon (en donnant le moins de détails possible, en faisant croire que toutes les versions de OpenSSH étaient vulnérables, etc. ...).
Une étude met dos-à-dos logiciels libres et propriétaires
Ross Anderson, chef du laboratoire d'informatique de l'université de Cambridge avance la théorie selon laquelle les logiciels propriétaires n'auraient pas plus de failles de sécurité que les logiciels « open source ».
En effet, le chercheur considère qu'un programme au code source ouvert est un programme dans lequels les bogues sont faciles à trouver ; à l'inverse, ils sont plus difficiles à détecter si le code est fermé.
En calculant, dans les deux cas, le temps moyen que mettra le programme à se planter, Anderson affirme que dans l'absolu les deux types de programmes présentent le même taux de sécurité.
Car l'atout du code ouvert - trouver plus facilement les bogues - constitue également un atout pour tous ceux qui veulent lancer des attaques.
Update: Frédéric Raynal ajoute un lien vers une traduction de la conclusion du-dit article. A lire si tout n'est pas clair pour vous...
En effet, le chercheur considère qu'un programme au code source ouvert est un programme dans lequels les bogues sont faciles à trouver ; à l'inverse, ils sont plus difficiles à détecter si le code est fermé.
En calculant, dans les deux cas, le temps moyen que mettra le programme à se planter, Anderson affirme que dans l'absolu les deux types de programmes présentent le même taux de sécurité.
Car l'atout du code ouvert - trouver plus facilement les bogues - constitue également un atout pour tous ceux qui veulent lancer des attaques.
Update: Frédéric Raynal ajoute un lien vers une traduction de la conclusion du-dit article. A lire si tout n'est pas clair pour vous...
Les détails de la faille d'OpenSSH
ISS vient de publier sur Bugtraq les détails de la faille d'OpenSSH.
Il s'agit d'un problème dans le mécanisme d'authentification "challenge-response".
Apparemment si OpenSSH est compilé sans les options SKEY ni BSD_AUTH, la vulnérabilité n'est pas exploitable.
De meme, utiliser la ligne suivante dans /etc/ssh/sshd_config résoudrait d'après eux le problème :
ChallengeResponseAuthentication no
Ben maintenant il reste plus qu'à tester tout ça, régler les quelques problèmes de conf engendrés.
Ca a quand même l'air moins dangereux que ce qui était annoncé précédemment et surtout moins difficile à règler (c'est pas une raison pour pas mettre a jour !).
Remarque : ISS met a disposition un outil pour tester si OpenSSH est vulnérable.
Note du modérateur : OpenSSH 3.4 est sorti (merci à falbala pour l'info)
Il s'agit d'un problème dans le mécanisme d'authentification "challenge-response".
Apparemment si OpenSSH est compilé sans les options SKEY ni BSD_AUTH, la vulnérabilité n'est pas exploitable.
De meme, utiliser la ligne suivante dans /etc/ssh/sshd_config résoudrait d'après eux le problème :
ChallengeResponseAuthentication no
Ben maintenant il reste plus qu'à tester tout ça, régler les quelques problèmes de conf engendrés.
Ca a quand même l'air moins dangereux que ce qui était annoncé précédemment et surtout moins difficile à règler (c'est pas une raison pour pas mettre a jour !).
Remarque : ISS met a disposition un outil pour tester si OpenSSH est vulnérable.
Note du modérateur : OpenSSH 3.4 est sorti (merci à falbala pour l'info)
Vulnérabilité OpenSSH
ISS, peu après avoir dévoilé le problème sur Apache, avait annoncé qu'ils travaillaient sur une faille d'un autre logiciel libre (en annonçant cette fois-ci que la démarche serait un peu différente !).
Encore Bind ? Sendmail ? Squid ?
Et bien non, OpenSSH... :-(
Les détails sur la faille ne sont pas encore connus mais on sait d'ors et déjà de la bouche de Théo de Raadt lui-même qu'elle sera exploitable à distance, sauf si la séparation de privilège récemment apparue est activée (« UsePrivilegeSeparation yes » dans sshd_config). Peu de distributions Linux proposent cette option pour le moment mais j'espère sincèrement qu'ils vont tous s'atteler pour que ce soit le cas avant la semaine prochaine, date fatidique à laquelle seront dévoilés les détails de l'exploit (et je pense qu'un exploit pas forcèment de Gobbles ne tardera pas à suivre...)
Plus de détails sur LinuxSecurity.com
Note d'un autre modérateur : voir sur debianplanet.org la source apt Debian pour avoir les paquets ssh et apache corrigés pour Woody, ainsi que Mozilla 1.0
Encore Bind ? Sendmail ? Squid ?
Et bien non, OpenSSH... :-(
Les détails sur la faille ne sont pas encore connus mais on sait d'ors et déjà de la bouche de Théo de Raadt lui-même qu'elle sera exploitable à distance, sauf si la séparation de privilège récemment apparue est activée (« UsePrivilegeSeparation yes » dans sshd_config). Peu de distributions Linux proposent cette option pour le moment mais j'espère sincèrement qu'ils vont tous s'atteler pour que ce soit le cas avant la semaine prochaine, date fatidique à laquelle seront dévoilés les détails de l'exploit (et je pense qu'un exploit pas forcèment de Gobbles ne tardera pas à suivre...)
Plus de détails sur LinuxSecurity.com
Note d'un autre modérateur : voir sur debianplanet.org la source apt Debian pour avoir les paquets ssh et apache corrigés pour Woody, ainsi que Mozilla 1.0
Version corrigée d'Apache
Une nouvelle version du serveur Web Apache vient de sortir, corrigeant les récents problèmes de sécurité. (NdM: 1.3.26)
Dans un même temps, la société ISS subit un retour de flamme du à sa "mauvaise conduite" lorsqu'elle a commencé le thread sur les problèmes de sécurité d'Apache.
En effet, la procédure (non-formelle) de rapport de bug prévoit que le fabricant d'un logiciel (ou le "groupe" qui développe un logiciel libre) soit mis au courant avant la publication...
ISS n'avait pas jugé nécessaire de le faire mais avait en plus proposé un patch qui ne résolvait pas complètement le problème !
Une nouvelle version pour apache 2.0 devrait apparaitre dans peu de temps...
Dans un même temps, la société ISS subit un retour de flamme du à sa "mauvaise conduite" lorsqu'elle a commencé le thread sur les problèmes de sécurité d'Apache.
En effet, la procédure (non-formelle) de rapport de bug prévoit que le fabricant d'un logiciel (ou le "groupe" qui développe un logiciel libre) soit mis au courant avant la publication...
ISS n'avait pas jugé nécessaire de le faire mais avait en plus proposé un patch qui ne résolvait pas complètement le problème !
Une nouvelle version pour apache 2.0 devrait apparaitre dans peu de temps...
faille dans apache
Une petite faille (buffer overflow) vient d'être annoncée sur securityfocus (ex bugtraq) concernant apache 1.x.
Il s'agit d'une erreur d'entier signé/non-signé pour allocation d'un tampon mémoire, qui peut-être exploitée, selon X-Force, découvreur du bug, sur les plate-formes WIN32 mais pas (pour l'instant ?) sur *n*x (NdM: il semblerait qu'on ait une erreur de segmentation du processus apache concerné si on a un Unix 32 bits et peut être plus embétant en 64 bits).
Note du modérateur: J'ai supprimmé le patch qui était inclus dans la news, vous pouvez le trouver sur le premier lien mais l'annonce d'apache indique qu'il ne corrige pas vraiment le problème.
Il s'agit d'une erreur d'entier signé/non-signé pour allocation d'un tampon mémoire, qui peut-être exploitée, selon X-Force, découvreur du bug, sur les plate-formes WIN32 mais pas (pour l'instant ?) sur *n*x (NdM: il semblerait qu'on ait une erreur de segmentation du processus apache concerné si on a un Unix 32 bits et peut être plus embétant en 64 bits).
Note du modérateur: J'ai supprimmé le patch qui était inclus dans la news, vous pouvez le trouver sur le premier lien mais l'annonce d'apache indique qu'il ne corrige pas vraiment le problème.