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
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.
Vers des logiciels plus sûrs ?
Les logiciels occupent une position privilégiée dans notre monde en ce qui concerne leurs défauts : si votre chaîne HiFi explose lorsque vous écoutez un album de Celine Dion, vous pouvez poursuivre le fabriquant et éventuellement obtenir des dommages et intérêts. Or cette cause ne s'applique pas aux éditeurs de logiciels qui, dans la plupart des cas, ne peuvent pas être poursuivis pour malfaçon grâce aux clauses de décharge contenues dans l'accord de licence que l'utilisateur doit accepter pour installer le produit.
Mais les choses vont peut-être changer et certains commencent à se poser des questions sur le statut des logiciels, produit ou service ?
Si cela est une bonne chose pour le consommateur, qu'en est-il des logiciels libres, pourrez-vous un jour être attaqués pour avoir laissé le code d'un de vos Hello World ayant fait exploser le nouveau Windows de M. DURAND ?
Note du modérateur : sur le même sujet, une dépêche de Boursorama proposée par modr12 (les deux dépêches étant issues de Reuters à la base)
Mais les choses vont peut-être changer et certains commencent à se poser des questions sur le statut des logiciels, produit ou service ?
Si cela est une bonne chose pour le consommateur, qu'en est-il des logiciels libres, pourrez-vous un jour être attaqués pour avoir laissé le code d'un de vos Hello World ayant fait exploser le nouveau Windows de M. DURAND ?
Note du modérateur : sur le même sujet, une dépêche de Boursorama proposée par modr12 (les deux dépêches étant issues de Reuters à la base)
Billou laisse les fenêtres ouvertes
Voici un nouveau problème dans les serveurs IIS de Microsoft qui fait préférer l'OpenSource...
Le fait que l'on puisse executer du code à distance sur le serveur IIS grâce à ce bug dans la gestion des requetes HTR n'est probablement pas le plus grave !
En effet, comme le dévoile un article de Wired, Microsoft avait passé un accord avec Eeye, à l'origine de la découverte du problème, et a pris tout son temps (plusieurs mois) pour sortir un patch...
Il est assez simple de voir en faisant une recherche dans Google avec "iis htr" comme mots clé que Eeye ne devaient pas etre les seuls à chercher ce genre de bugs ;-)
Donc MS à préféré cacher pendant des mois le problème plutot que de sortir un correctif rapidement.
La NSA, apparemment au courant aurait conseillé pendant plusieurs mois d'enlever la fonctionnalité la plupart du temps inutile mais activée par défaut... No comment.
Le fait que l'on puisse executer du code à distance sur le serveur IIS grâce à ce bug dans la gestion des requetes HTR n'est probablement pas le plus grave !
En effet, comme le dévoile un article de Wired, Microsoft avait passé un accord avec Eeye, à l'origine de la découverte du problème, et a pris tout son temps (plusieurs mois) pour sortir un patch...
Il est assez simple de voir en faisant une recherche dans Google avec "iis htr" comme mots clé que Eeye ne devaient pas etre les seuls à chercher ce genre de bugs ;-)
Donc MS à préféré cacher pendant des mois le problème plutot que de sortir un correctif rapidement.
La NSA, apparemment au courant aurait conseillé pendant plusieurs mois d'enlever la fonctionnalité la plupart du temps inutile mais activée par défaut... No comment.
Déni de service dans x-window
Lors d'utilisation de fontes anormalement grandes, il est possible de geler un PC utilisant X-window...
L'expérience peut etre tentée avec Gimp, mais le plus dangereux reste encore le deni de service à distance grace à Mozilla, lorsque les fontes se voient assignées une valeur trop grande dans les CSS (Cascading Style Sheets).
Le travail est en cours pour résoudre le problème mais il n'y a pas encore de solution pour éviter le bogue...
L'expérience peut etre tentée avec Gimp, mais le plus dangereux reste encore le deni de service à distance grace à Mozilla, lorsque les fontes se voient assignées une valeur trop grande dans les CSS (Cascading Style Sheets).
Le travail est en cours pour résoudre le problème mais il n'y a pas encore de solution pour éviter le bogue...
Vulnérabilité de type DoS sur BIND 9
Une vulnérabilité de type DoS (déni de service) a été découverte sur BIND 9. L'exploitation de cette vulnérabilité se fait grâce à la construction d'un paquet malformé qui aura pour effet d'arrêter le service BIND. L'impact d'une telle attaque peut être grave dans la mesure où beaucoup de services importants tels que la messagerie dépendent du DNS pour fonctionner correctement.
Il est recommandé de mettre à jour BIND à la version 9.2.1. Il est à noter que les versions 8 et 4 ne sont pas concernées par cette vulnérabilité.
Il est recommandé de mettre à jour BIND à la version 9.2.1. Il est à noter que les versions 8 et 4 ne sont pas concernées par cette vulnérabilité.