Articles précédents : Logiciel
- [69] GNOME Office 1.0
- [29] Sortie de Xawdecode [xdTV] version 1.8.0
- [27] Sortie de Open SSH 3.7
- [20] OpenBSD 3.4 bientôt dans les bacs
- [13] Sortie de Kde 3.2 alpha 1
- [67] GNOME 2.4 est disponible
- [9] Open Office en RC4 : bientôt la finale
- [33] Thunderbird 0.2 est disponible
- [33] Wherever Racer (Tux revient !)
- [46] GNOME Desktop 2.4 Release Candidate 1
Liens connexes
- Site Sendmail (663 hits)
- Référence FullDisclosure (619 hits)
- Site officiel de OpenSSH (826 hits)
- Dépêche précédente sur la sortie de OpenSSH 3.7 (663 hits)
- L'alerte sur le site du CERT Coordination Center (650 hits)
Dépêche modérée par
Logiciel : Faille Sendmail et vulnérabilité OpenSSH
Posté par jr lamoule (page perso, ). Modéré le 18 septembre 2003.Faille dans sendmail (exploitable en local).
Une nouvelle faille de sécurité vient d'être trouvée
dans Sendmail (y compris le 8.12.9). Le site Sendmail n'est pas encore à jour, mais le patch est déjà disponible.
Samuel DUBUS nous apprend l'existence d'...
Une vulnérabilité dans la nouvelle version de OpenSSH !
Alors que la nouvelle version de OpenSSH vient à peine de sortir il y a deux jours, une vulnérabilité permettrant un déni de service sur le démon OpenSSH vient d'etre découverte. Cette vulnérabilité est exploitable sur toutes les versions d'OpenSSH jusqu'à la version 3.7. Une nouvelle version est déjà disponible sur le site de OpenSSH : la 3.7.1.
Alors, pour ceux qui ne sont pas à jour ... direction le site de téléchargement d'OpenSSH.
Site Sendmail (663 hits)
Référence FullDisclosure (619 hits)
Site officiel de OpenSSH (826 hits)
Dépêche précédente sur la sortie de OpenSSH 3.7 (663 hits)
L'alerte sur le site du CERT Coordination Center (650 hits)
> Lire la dépêche (73 commentaires, moyenne: 2,5).
RCS file: /cvs/src/gnu/usr.sbin/sendmail/sendmail/parseaddr.c,v
retrieving revision 1.16
diff -u -r1.16 parseaddr.c
--- parseaddr.c 29 Mar 2003 19:44:01 -0000 1.16
+++ parseaddr.c 16 Sep 2003 17:37:26 -0000
@@ -700,7 +700,11 @@
addr[MAXNAME] = '\0';
returnnull:
if (delimptr != NULL)
+ {
+ if (p > addr)
+ p--;
*delimptr = p;
+ }
CurEnv->e_to = saveto;
return NULL;
}
Re: Faille sendmail et vulnérabilité OpenSSH
la vulnéralité n'est pas prouvé encore...
cela reste une correction de bug, l''exploit serait dans la nature, mais aucun expert n'en donne une trace.
Quand les whitehat donne l'exploit tout va bien, mais si les blackhat garde les exploits pr eux il y a peu de chance, d'être sur des faisablités.
Reste les honeypots mais faut il qu'il soit intéréssant pour attirer
ces tentatives.
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par _PinG _ () le 18/09/2003 à 07:48. (lien). Évalué à 6.Pour SSH, ce "bug" (si tu tiens à l'appeler ainsi) aprait tout de même beaucoup plus exploitable que le précédent... disont qu'il est quand même fort probable vu la tronche du problème d'en sortir un exploit... Et quoi qu'il advienne, même si tu doute, autant patcher...
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par _PinG _ () le 18/09/2003 à 07:52. (lien). Évalué à 14.je me réponds à moi même pour rajouter l'explication de Franck Denis ici même mais sur la news précédente (pour ne pas 'voler' l'explication) : http://linuxfr.org/comments/270995.html(...)
Et pour ceux qui ne veulent pas cliquer :
Dans le premier cas lors de la libération il y a 32K de zeros supplémentaires qui sont écrits. 32k c'est beaucoup, ca bousille toutes les structures qui suivent et à part un crash, on ne peut pas en tirer grand chose.
Dans le second cas ce ne sont que 10 octets supplémentaires qui sont écrits, on peut donc (suivant l'implémentation de malloc) toucher quelque chose d'intéressant juste après, et changer la taille d'un bloc utilisé par la suite.
D'autre part le premier bogue s'obtient en cas de saturation de mémoire.
Le second est beaucoup moins aléatoire à provoquer.-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Misc (page perso, ) le 18/09/2003 à 09:25. (lien). Évalué à 4.La saturation de mémoire, c'est pas trés aléatoire à provoquer, à mon sens :)
La vrai question est de savoir ce que la libération d'une zone mémoire peut provoquer. Prenons une variable qui serait touché par ce "nettoyage", sous quelle condition peut t'on exploiter ça ?
A part un pointeur à moitié effacé, qui pointerai du coup sur une autre zone, qui serait théoriquement sous le controle du pirate, je voit pas trop. Et, ça ne me semble pas être trés trivial.
Et sauf erreur de ma part, c'est suivi par un appel à fatal, qui se traduit par un message d'erreur et un exit, non ?
Donc, il faut réussir à corrompre la section .dtors ( éxecuté à la fermeture, pour les programmes compilés par gcc ) pour exploiter ça, ou réussir à corrompre l'appel à fatal, ou à exit, ou à une fonction, ce qui me semble donc être plus facile à exploiter par la suite.
Si jamais on arrive justement à corrompre un de ces éléments, alors, la faille est dans la corruption, et pas dans le crash. Car la charge se déclencherai alors lors d'une extinction ( exemple, un upgrade ), ce qui est tout aussi mauvais.
J'ai bon, ou je raconte des conneries ?
J'ai peut être oublié quelque chose dans mon raisonnement.
-
-
-
[^]Le CERT annonce les vulnérabilités: c'est un organisme hyper crédible !!
Posté par Wharf () le 20/09/2003 à 14:02. (lien). Évalué à 2.Pour moi, à chaque fois que le CERT annonce une vulnérabilité, c'est à prendre au sérieux !!
Par contre en France, le CERTA ne publie que celle de OPENSSH et pas cette nouvelle faille de Sendmail.
http://www.certa.ssi.gouv.fr/site/CERTA-2003-AVI-152/index.html.2.h(...)
La précédente faille de SendMail publièe par le CERTA datait du 3septembre:
http://www.certa.ssi.gouv.fr/site/CERTA-2003-AVI-141/index.html.2.h(...)
CERT issued an advisory on Tuesday for the OpenSSH vulnerability and another on Thursday for the Sendmail flaw.
http://www.cert.org/advisories/CA-2003-24.html(...)
The OpenSSH issue affects versions before 3.7.1 and occurs as a problem in the way the software stores chunks of data using storage areas called buffers. Cisco said it has products that are affected, while Red Hat, Sun Microsystems and IBM's AIX Toolbox for Linux all use versions of OpenSSH that could be vulnerable.
http://www.cert.org/advisories/CA-2003-25.html(...)
The Sendmail flaw affects versions before 8.12.10. HP, IBM and Red Hat are among the software makers that use Sendmail and whose products could be affected.
A propos, avez vous aussi vu la vulnérabilité mySQL du 16 septembre ?
http://www.certa.ssi.gouv.fr/site/CERTA-2003-AVI-151/index.html.2.h(...)
Re: Faille sendmail et vulnérabilité OpenSSH
Et dire qu'il y a moins d'une journée que je signalais que Slackware fournissait malheureusement Sendmail (http://linuxfr.org/~kapouik/5424.html(...)) alors qu'il existe des serveurs de messagerie bien plus sécurisés et pratique ! Comme quoi, malgré ce que disent les fervents défenseurs de sendmail, l'actualité confirme cet état de fait : sendmail a rendu de nombreux services mais des alternatives mieux pensées s'imposent au fil du temps (postfix, exim, qmail, ...).
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Austin () le 18/09/2003 à 08:08. (lien). Évalué à 5.> mais des alternatives mieux pensées s'imposent au fil du temps (postfix, exim, qmail, ...).
Les concurrents sont peut-être géniaux mais il y a un fait qu'il ne faut pas oublier :
- l'erreur est humaine
De plus faire croire qu'il existe des méthodes miracles pour ne pas avoir de trou de sécurité est du pipo et me fait penser à certaines propagandes (forts prometteuses) de microsoft.-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Annah C. Hue (page perso, ) le 18/09/2003 à 09:04. (lien). Évalué à 8.Salut Steeve,
S'il n'y a pas de méthodes miracles pour programmer des soft dépourvus de bugs (et donc de trous de sécurité), il y a quand même moyen de limiter grandement les risques en suivant quelques conseils, comme ceux qu'ont peut trouver là http://www.dwheeler.com/secure-programs/(...)-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Arnaud (page perso, ) le 18/09/2003 à 21:31. (lien). Évalué à 1.Pour commencer, il faudrait utiliser des langages à la base un peu plus sécure (ex: Ada ;-) mais ça limite de suite beaucoup le nombre de développeurs potentiels, dommage :-(
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par alenvers () le 18/09/2003 à 21:46. (lien). Évalué à 4.Ben, perso, je ne suis pas trop attaché à un langage. Il me faut généralement quelques heures pour débrouiller dans un nouveau langage. En moins d'une semaine, je peux programmer.
Un bon informaticien ne doit pas être dépendant d'un langage, il doit penser selon son propre formalisme. Le reste n'est que traduction d'un formalisme vers un autre. C'est d'ailleur pour ça que j'ai tendance quand je code en C de faire de l'OO (parce que je trouve l'OO facile pour bcps de chose) alors que le C n'est pas à priori un langage OO (il m'est même arrivé de faire des closures).
Les concepts sont transposables dans tous les langages (pratiquement) c'est seulement plus compliqué d'y arriver avec certains que d'autres.
A part ça, j'ai déja fait de l'Ada. Et je n'ai pas trop apprécié. L'ada (comme l'IPv6) est un chaudron dans lequel des centaines de scientifiques ont mis leur touche ce qui donne un beau bordel avec des tonnes de features. Les concepts sont bien beau mais l'implementation est très moche. L'OO par exemple est aussi bien foutu qu'en perl (attention : troll poilu).
-
-
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par syntaxerror () le 18/09/2003 à 09:10. (lien). Évalué à 5.Non, il n'existe pas de méthode miracle, mais de sains principes de développement
qui permettent de limiter les conséquences d'une erreur (en matière de sécurité et autres).
Sendmail est un bon exemple de ce qu'il ne faut pas faire même si son age canonique
et ses origines l'excusent en partie.-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Austin () le 18/09/2003 à 09:59. (lien). Évalué à 3.> mais de sains principes de développement qui permettent de limiter les conséquences d'une erreur (en matière de sécurité et autres).
Exemple d'application de ces sains principes sur ce trou de sécurité de sendmail ?
Et autre chose que l'audit du code.
> Sendmail est un bon exemple de ce qu'il ne faut pas faire
Tu peux dire la dernière foi où il y a eu une "catastrophe" avec sendmail ?
Je veux dire un exploit avec perte de donnée ou serveur inutilisable et que les média en ont parlé.
> même si son age canonique et ses origines l'excusent en partie.
L'age n'a rien à voir.
Linux (le noyau) a plus souvent des trous de sécurité que sendmail et il est récent. Le dernier gros problème est avec modutils et gnu.org s'en rappèle.
Linux est pour toi aussi un "bon exemple de ce qu'il ne faut pas faire" ?-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par matli () le 18/09/2003 à 11:08. (lien). Évalué à 4.D'ailleurs, en terme d'âge, on peut presque les comparer puisque la série des V8 de Sendmail a commencé en 1992. A cette époque, Eric Allman avait plus ou moins laissé son bébé en l'état, d'autres développeurs y étaient aller de leur propre mouture. Eric Allman a alors décidé de tout reprendre en intégrant différentes fonctionnalitées présentes dans les autres moutures. La série des V8 n'a a priori pas grand chose à voir avec delivermail et les versions suivantes de Sendmail.
Tout cela pour dire qu'il faut arrêter de taper sur Sendmail sous prétexte que c'est vieux et patati et patata. Le fait qu'il soit encore aussi présent sur le net n'est pas uniquement lié à son aspect historique ou à son âge vénérable. Sendmail est un très bon MTA, l'un des meilleurs en terme de montée en charge (raison pour laquelle RedHat en fait son MTA par défaut) et l'un des plus souples en terme de configuration. Des failles? Comme le précise Austin, elles n'ont pour l'instant pas engendré de catastrophes (ce qui n'empêche pas d'être vigilent) et les développeurs sont réactifs.
Simplement, c'est à son approche que l'on fait la différence entre les hommes et les petits garçons....-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par alenvers () le 18/09/2003 à 21:13. (lien). Évalué à 5.>sous prétexte que c'est vieux
Non c'est pas parce que c'est vieux ! Sendmail utilise plutot l'adage : "ce qui est compliqué est bien !". Moi, j'ai toujours cru que dans SMTP, il y avait SIMPLE. La conf d'un sendmail est une merdouille.
>Le fait qu'il soit encore aussi présent sur le net
Ce n'est pas parce qu'un prog est le plus utilisé qu'il est le meilleur !-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par matli () le 19/09/2003 à 07:08. (lien). Évalué à 3.La conf d'un sendmail n'est pas une merdouille si tu renonces à éditer directement le sendmail.cf, chose qui est écrite un peu partout dans la doc, les newsgroups,... Il suffit d'utiliser les macros m4, et là, je suis désolé, mais on peut couvrir la quasi totalité des besoins avec un fichier de macro de quelques lignes lisibles par un être humain. RTFM
-
-
-
-
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par marmotte_57 (Jabber id, ) le 18/09/2003 à 09:37. (lien). Évalué à 2.De plus faire croire qu'il existe des méthodes miracles pour ne pas avoir de trou de sécurité est du pipo et me fait penser à certaines propagandes (forts prometteuses) de microsoft.
Et on fait quoi de l'Atelier B ? Parce qu'un prof me soutenait que ça permettait de faire des choses sans faille, une fois qu'on avait tout prouvé par ce truc. (pas de troll sur les profs, merci pour eux...)-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Pierre Tramo (page perso, ) le 18/09/2003 à 10:01. (lien). Évalué à 3.Et on fait quoi de l'Atelier B ? Parce qu'un prof me soutenait que ça permettait de faire des choses sans faille, une fois qu'on avait tout prouvé par ce truc.
Oui, tu peux prouver formellement qu'un programme est conforme à une modélisation. Ensuite, il peut toujours y avoir des erreurs dans la modélisation (mais c'est vrai qu'il est plus facile de se "convaincre" de l'exactitude d'une modélisation que de celle d'un programme). Et le prouveur peut aussi être buggé, mais là ça serait vraiment pas de chance ;).
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Matthieu Moy (page perso, ) le 18/09/2003 à 10:34. (lien). Évalué à 4.Oui, on peut faire des programmes garantis sans buffer overflow.
Sans aller chercher jusqu'à l'Atelier B, il suffit de programmer en Java ou en Ada, ou n'importe quel language qui implémente des verification de débordement de tableau et autres à l'execution. (en Ada, en cherchant bien, il doit y avoir moyen de faire pointer un pointeur dans le vide, mais en Java, le pointeur est initialisé à null, et la mémoire n'est désallouée que par le garbage collector, donc, seulement lorsque personne ne pointe dessus.)
MAIS ces vérifications à l'execution sont une perte de temps dans beaucoup de cas ou le programmeur est sur qu'il écrit dans la zone mémoire qu'il veut. Pour des applications destinées à des serveurs, cette perte de temps de calcul serait intolérable.
Pour ce qui est de l'atelier B, il y a si mes souvenirs sont bons 500 hommes.mois de travail pour 50 000 lignes de code pour le métro météor. Fais une règle de trois pour voir ce qu'il faudrait pour le code d'un gros projet, et tu verras que ce n'est pas n'importe qui qui peut se le permettre.-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Arnaud (page perso, ) le 18/09/2003 à 21:38. (lien). Évalué à 1.Je ne suis pas d'accord sur la perte de temps des vérifications dynamiques : si on compare le surcoût d'une machine un peu plus puissante, je suis sur qu'on arrive bien dessous des coûts liés aux failles de sécuritées qui auraient ainsi pu être invitées (c'est que ça revient cher à l'heure, un administrateur).
Et n'oublions pas qu'avec des bons compilos Ada (vive GNAT!), beaucoup des vérifications dynamiques sont tout simplement supprimées, quand le compilo "prouve" qu'en tout cas à l'éxécution, il n'y a forcément pas de problèmes.-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Christophe BAEGERT () le 19/09/2003 à 17:19. (lien). Évalué à 1.Tu sous-estimes le cout du matos. Avec beaucoup de trafic, tu tombes n'importe quel serveur quadri-machin si tu programmes dans un language lent (suivez mon regard)
-
-
-
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
-
Re: Faille sendmail et vulnérabilité OpenSSH
> Alors, pour ceux qui ne sont pas à jour ... direction le site de download de OpenSSH.
Direction sa distribution en premier. J'ai contrôlé pour RedHat et Mandrake et les correctifs sont dispos (J'ai pas contrôlé les autres).
RedHat indique qu'il n'y a pas encore d'exploit du trou de sécurité de sendmail mais qu'un exploit est potentiellement possible à distance. Le trou n'existe pas pour la configuration par défaut.
Par contre pour OpenSSH c'est plus urgent.
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Boa Treize (page perso, ) le 18/09/2003 à 07:57. (lien). Évalué à 2.Le dernier dernier OpenSSH ainsi que le dernier Sendmail sont dans Slackware (8.1, 9.0 et -current).
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par B. franck () le 18/09/2003 à 08:12. (lien). Évalué à 2.Direction sa distribution en premier. J'ai contrôlé pour RedHat et Mandrake et les correctifs sont dispos
comme j'aurais aimé trouver un lien vers ces correctifs !-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Austin () le 18/09/2003 à 08:27. (lien). Évalué à 5.http://www.mandrakesecure.net/en/advisories/advisory.php?name=MDKSA(...)
http://www.mandrakesecure.net/en/advisories/advisory.php?name=MDKSA(...)
https://rhn.redhat.com/errata/RHSA-2003-279.html(...)
https://rhn.redhat.com/errata/RHSA-2003-283.html(...)
https://rhn.redhat.com/errata/RHSA-2003-280.html(...)
https://rhn.redhat.com/errata/RHSA-2003-284.html(...)
Tous les correctifs :
http://www.redhat.com/apps/support/errata/(...)
http://www.mandrakesecure.net/en/advisories/(...)
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Austin () le 18/09/2003 à 08:29. (lien). Évalué à 2.Toutes les distributions ont des outils pour installer les correctifs sans les chercher.
-
[+] [^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Pierre Tramo (page perso, ) le 18/09/2003 à 09:41. (lien). Évalué à -1.Toutes les distributions ont des outils pour installer les correctifs sans les chercher.
Même la Slackware ?
-
-
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par _PinG _ () le 18/09/2003 à 08:31. (lien). Évalué à 3.Pour debian, sendmail (cf le [DSA-384-1]) et OpenSSH (cf le [DSA-383-1]) sont corrigés. Tous les liens pour mettre à jour sont dans les mails ci-dessous (et bien sur dans security...)
OpenSSH [DSA-383-1] : http://lists.debian.org/debian-security-announce/debian-security-an(...)
Sendmail [DSA-384-1] : http://lists.debian.org/debian-security-announce/debian-security-an(...)
Pour les problèmes précédents d'OpenSSH :
[DSA-382-1] : http://lists.debian.org/debian-security-announce/debian-security-an(...)
[DSA-382-2] : http://lists.debian.org/debian-security-announce/debian-security-an(...)-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par _PinG _ () le 18/09/2003 à 08:55. (lien). Évalué à 2.oops...
pour Sendmail [DSA-384-1], il falait bien sur lire http://lists.debian.org/debian-security-announce/debian-security-an(...) ... J'ai du me tromper de tab en copiant-collant.
Désollé.
-
Re: Faille sendmail et vulnérabilité OpenSSH
Codées avec les pieds ou pas, l'avantage des applications opensource c'est le temps de réactivité pour les propositions de corrections... Quand le problème est connu.
en route pour un update...
--
-
[^]Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Éric (Jabber id, page perso, ) le 18/09/2003 à 08:27. (lien). Évalué à 7.s/connu/public/ (ce qui fait une grosse différence)
Re: Faille sendmail
Euh, la faille sendmail est exploitable a distance :
http://www.secunia.com/advisories/9758/(...)
Faudrait rectifier la news qui dit : "Faille dans sendmail ( exploitable en local ).".
Steph
-
[+] [^]Re: Faille sendmail
Posté par Austin () le 18/09/2003 à 10:03. (lien). Évalué à -1.> Euh, la faille sendmail est exploitable a distance :
Où tu vois ça ?
Je vois seulement :
Description:
A vulnerability has been identified in sendmail possibly allowing malicious people to gain system access.
The problem has been identified in the "prescan()" function. Different attack vectors are possible. No further information is available.-
[^]Re: Faille sendmail
Posté par FRLinux (page perso, ) le 18/09/2003 à 10:35. (lien). Évalué à 7.Critical: Highly critical
Impact: System access
Where: From remote
-
Alternative à OpenSSH
Je suis légèrement saoulé de patcher 10 fois par an mon serveur SSH, surtout vu la criticité de ce logiciel. De quelles alternatives à OpenSSH dispose-t-on réellement ?
Il y a bien sûr les alternatives propriétaires, mais pour diverses raisons elles ne m'intéressent pas.
Des idées ?
-
[^]Re: Alternative à OpenSSH
Posté par FRLinux (page perso, ) le 18/09/2003 à 13:32. (lien). Évalué à 0.Tu peux commencer par patcher ton petit Linux (considerant que c'est un linux que tu tournes) avec un patch genre http://www.grsecurity.net(...) ce sera un debut.
C'est beau de se plaindre d'un produit opensource, tu devrais leur ecrire ... Tu peux aussi lancer ton projet en fork et voir combien vont suivre, apres tout c'est aussi une des forces du libre, t'est pas content, tu fais mieux.
J'ai rien contre toi mais ta remarque m'a fait monter mon taux de cafeine deja extremement eleve ...
Tiens, j'entends une voix... un cri... la porte ? d'accord.
Steph-
[^]Re: Alternative à OpenSSH
Posté par Sylvain Briole (page perso, ) le 18/09/2003 à 15:39. (lien). Évalué à 6.C'est beau de se plaindre d'un produit opensource, tu devrais leur ecrire ... Tu peux aussi lancer ton projet en fork et voir combien vont suivre, apres tout c'est aussi une des forces du libre, t'est pas content, tu fais mieux.
J'ai rien contre toi mais ta remarque m'a fait monter mon taux de cafeine deja extremement eleve ...
Il se plaint un tantinet OK, mais une telle demande n'a rien de si négatif.
Il voudrait juste se renseigner si une alternative à OpenSSH existe et je trouve que cela n'a rien de négatif.
C'est comme si un gars postait : "j'en ai marre de patcher mon Sendmail 10 fois par an, existe-t'il une alternative?", et là, on lui répondrait "postifx, exim, qmail, ...".
J'avoue que, perso', je me pose aussi la question d'alternatives à OpenSSH, pas en raison de ses trous de sécu', mais tout simplement parce que l'avantage du libre c'est souvent : "il y a plus d'une manière de résoudre un problème".
-
-
[^]Re: Alternative à OpenSSH
Posté par earxtacy (Jabber id, ) le 18/09/2003 à 13:32. (lien). Évalué à 6.t'as du choix ici:
http://www.lysator.liu.se/~nisse/lsh/(...)
mais je pense qu'openssh va finir par etre robuste.-
[^]Re: Alternative à OpenSSH
Posté par Gloo () le 18/09/2003 à 20:07. (lien). Évalué à 0."je pense qu'openssh va finir par etre robuste"
Je pense que les produits microsoft aussi. mdr...
Blagues à part, openssh rejoindra probablement sendmail et bind sur pas mal de machines ( /dev/null ), dès qu'une alternative serieuse se presentera.-
[^]Re: Alternative à OpenSSH
Posté par earxtacy (Jabber id, ) le 18/09/2003 à 21:03. (lien). Évalué à 1.Sauf qu'openSSH est opensource et plus de monde a les yeux dessus....
-
[^]Re: Alternative à OpenSSH
Posté par Gloo () le 18/09/2003 à 22:13. (lien). Évalué à 0.ouaip ouaip... Sendmail et bind aussi sont opensource. /dev/null je te dis. opendource ou pas, il y a un moment où il faut jeter le soft.
openssh commence à entrer severement dans cette categorie.-
[^]Re: Alternative à OpenSSH
Posté par Bertrand Usse (page perso, ) le 19/09/2003 à 11:47. (lien). Évalué à 1.Quels sont les alternatives à ISC BIND (Si c'est aussi évident) libre ou opensource, évidemment ?
J'ai beau chercher je ne trouve pas ... je dois mal chercher. Une suggestion ?--
~~~~-
[^]Re: Alternative à OpenSSH
Posté par bmc () le 19/09/2003 à 12:48. (lien). Évalué à 1.MaraDNS (domaine public): http://www.maradns.org/(...) si tu cherches un serveur d'autorité.
DNSMasq ou PDNSD (tous deux GPL): http://www.thekelleys.org.uk/dnsmasq/doc.html(...) et http://www.phys.uu.nl/~rombouts/pdnsd.html(...) si tu cherches un serveur récursif uniquement.
Ayant testé MaraDNS et DNSMasq, je peux dire qu'ils fonctionnent tous deux fort correctement. Je n'ai bien sûr pas testé dans des conditions extrèmes, mon utilisation étant très limitée.
-
[^]Re: Alternative à OpenSSH
Posté par Olivier Jeannet () le 19/09/2003 à 17:40. (lien). Évalué à 2.Quels sont les alternatives à ISC BIND (Si c'est aussi évident) libre ou opensource, évidemment ?
Le djbdns est pas mal du tout, mais il n'implémente pas certains trucs. C'est fait par le réputé (en terme de sécurité) Daniel J. Bernstein, un mathématicien. Il a aussi fait qmail. Utilise Google pour l'URL, je ne l'ai pas sous la main.
Je le mentionne car ça dérange certaines, sa licence est un peu particulière car il n'autorise pas la redistribution de ses sources modifiées, seulement des sources + patches. La raison est qu'il garantit son code (il a tout audité soigneusement).
-
-
[^]Re: Alternative à OpenSSH
-
-
-
-
[^]Re: Alternative à OpenSSH
Posté par unk () le 18/09/2003 à 20:29. (lien). Évalué à 3.Il existe aussi DropBear, qui n'utilise pas la bibliothèque SSL ; de plus, lié statiquement avec la µClibc, l'exécutable fait moins de 200 Ko. Note, il n'implémente que SSH2 et il n'y a pas de scp/sftp. On peut faire du X11-Forwarding (jamais essayé), mais pas de port forwarding.
http://matt.ucc.asn.au/dropbear/dropbear.html(...)
La configuration est un peu spartiate (certaines options ne sont modifiables que dans un .h avant la compilation), et ce n'est peut-être pas non plus le serveur sshd le plus "secure". Mais pour un environnement léger ou en tant que service lancé quand on a besoin de mettre à jour un OpenSSH sur une machine distante, c'est vachement utile.-
[^]Re: Alternative à OpenSSH
-
[^]Re: Alternative à OpenSSH
-
-
-
[^]Re: Alternative à OpenSSH
Posté par Jean-Michel Besnard (page perso, ) le 18/09/2003 à 15:28. (lien). Évalué à 1.Sous debian ( et ca doit surement etre la meme chose sous d'autres distributions), tu fais un apt-get update && apt-get upgrade et on en parle plus.
Donc franchement c'est pas la mort, ca prend une minute par machine.-
[^]Re: Alternative à OpenSSH
Posté par titi toto (Jabber id, ) le 19/09/2003 à 08:46. (lien). Évalué à 2.ca m'aurait etonne qu'y ait pas un qui la ramene avec sa debian et son apt-get, pour changer..
personne pour dire "gentoo roxor, emerge world" (tapez pas si c'est pas la bonne commande, j'en sais rien)-
[^]Suffit de demander
Posté par Brice Arnould ( un_brice ) (page perso, ) le 21/09/2003 à 11:43. (lien). Évalué à 1.G3N2 r0x0r!
emerge sync && emerge -uD world--
Respect à RMS.
-
-
-
[^]Re: Alternative à OpenSSH
-
[^]Re: Alternative à OpenSSH
Posté par Wawet76 (page perso, ) le 18/09/2003 à 23:09. (lien). Évalué à 3.À noter que parfois les alternatives ont aussi des failles mais comme moins de monde les utilisent, on en entend moins parler (voir, on ne les voie pas parcequ'on ne les cherche pas)
C'est une facette de la sécurité que je trouve rigolote et intéressante : avec de la diversité dans les applis, il n'y a pas de faille qui touche tout le monde. Souvenez vous de je ne sais plus qui (armée US ?) qui avait annoncé qu'ils allaient mettre leurs serveurs web sous MacOS uniquement parceque moins de crackers connaissaient ce système.
Vive les alternatives !-
[^]Re: Alternative à OpenSSH
Posté par bmc () le 18/09/2003 à 23:31. (lien). Évalué à 3.Tout à fait, je suis conscient que tout logiciel a ses failles. Néanmoins, la position d'OpenSSH est dangereuse: il n'existe actuellement (ou bien je n'en suis pas informé) aucune alternative libre et sérieuse. On est en quelque sorte «coincé» sous OpenSSH, et c'est typiquement le genre de choses qui me hérisse, même si c'est un projet libre et plutôt bien foutu dans l'ensemble.
Je ne cherche pas à dévaloriser le travail des mainteneurs d'OpenSSH, c'est certainement un bout de code très complexe, mais d'autres projets s'en tirent très bien en étant autant sinon plus utilisés (je pense à Postfix autant qu'à Pureftpd et à bien d'autres). Bref, il y a des failles dans tout logiciel mais le but du concepteur est de les limiter, et ça n'est pas vraiment ça que l'on voit avec OpenSSH. Il y a vraiment eu trop d'alertes de sécurité de ce côté pour que l'on puisse réellement être tranquille en ayant un serveur SSH sur sa machine. Il est donc logique de chercher une alternative, qui sera peut-être moins sécurisée mais que l'on pourra au moins tester ou sur laquelle on pourra se rabattre en cas d'urgence.
-
[^]Re: Alternative à OpenSSH
Posté par Pierre Jarillon (page perso, ) le 19/09/2003 à 01:43. (lien). Évalué à 2.Ll y a trois ans, j'ai même vu dans une entreprise une machine avec un OS propriétaire complètement oublié servir de frontal avec le monde extérieur. Le motif était de dire que vu qu'il n'y avait pas plus d'une dizaine de personnes qui connaissent encore l'OS et le processeur, la probabilité de craquage est quasi nulle.
-
[^]Re: Alternative à OpenSSH
-
-
Une bien bonne sur Sendmail
J'en ai entendu une bien bonne: "Sendmail has more exploitable holes than a parade of hookers" ... je traduirais pas :)
-
[^]Re: Une bien bonne sur Sendmail
Buffers Overflows
Salut,
Je ne suis pas un expert de sécurisé informatique mais je me pose les questions suivantes :
Un buffer overflow consiste à écrire au delà de l'allocation prévue d'un tableau par exemple. Afin de modifier le code retour d'une fonction,
ainsi lorsqu'elle se termine, on fait exécuter du code prélablement placé dans le tableau.
D'après ce que j'ai lu, l'architecture intel ne permet pas de faire
des pages de mémoire soit READ soit EXECUTABLE, c'est forcément
les 2 à la fois. D'ou les problèmes de sécurité, si on pouvait rendre
les zones mémoires de données non éxécutable au niveau matériel.
Suite à cela voici mes questions :
Les autres architectures sont elles sujettes aux même problèmes ? existe t'il par exemple des buffers overflows sur les PowerPC ?
Ne serait-il pas possible de modifier les normes d'appels de fonctions afin
que le code de retour des fonctions soit ailleurs dans un endroit protégé, non modifiable ?
A+
Nicolas.
-
[^]Re: Buffers Overflows
Posté par _PinG _ () le 20/09/2003 à 12:07. (lien). Évalué à 1.Le format d'executable Elf permet de définir si une page sera accessible en Ecriture mais pas en Execution (grace au Code Segment Limit), ou l'inverse...
OpenBSD a passé son format d'exe i386 en Elf pour ca notement.
cf :
Explication de l'implémentation de W^X : http://marc.theaimsgroup.com/?l=openbsd-misc&m=105056000801065&(...)
Format Elf : http://www.openbsd.org/cgi-bin/man.cgi?query=elf(...)
[+] Re: Faille Sendmail et vulnérabilité OpenSSH
[+] Buffers Overflows
Salut,
Je ne suis pas un expert en sécurisé informatique mais je me pose les questions suivantes :
Un buffer overflow consiste à écrire au delà de l'allocation prévue d'un tableau par exemple. Afin de modifier le code retour d'une fonction,
ainsi lorsqu'elle se termine, on fait exécuter du code prélablement placé dans le tableau.
D'après ce que j'ai lu, l'architecture intel ne permet pas de faire
des pages de mémoire soit READ soit EXECUTABLE, c'est forcément
les 2 à la fois. D'ou les problèmes de sécurité, si on pouvait rendre
les zones mémoires de données non éxécutable au niveau matériel.
Suite à cela voici mes questions :
Les autres architectures sont elles sujettes aux même problèmes ? existe t'il par exemple des buffers overflows sur les PowerPC ?
Ne serait-il pas possible de modifier les normes d'appels de fonctions afin
que le code de retour des fonctions soit ailleurs dans un endroit protégé, non modifiable ?
A+
Nicolas.
-
[^]Re: Buffers Overflows
Re: L'année 2003 se termine mal !!
Voici un bilan des vulnérabilitès publièes depuis le 1er janvier 2003: pas franchement glorieux pour la profession !!!
total des bulletins - toutes versions confondues par éditeur d'OS (sauf détail pour Sun Solaris/Linux) - Félicitations à OpenBSD !! le moins mauvais de la classe
OpenBSD 14
SunLinux 21
Trustix 22
EnGarde 27
Microsoft Windows 30
SuSE 39
Sun Solaris 47
Mandrake 95
RedHat 97
Debian 166
répartition des bulletins Microsoft par version d'OS (Les 30 bulletins ci-dessus concernent en général plusieurs versions)
Windows 2000 24
Windows XP 23
Windows Server 2003 9
Bulletins des 7 derniers jours (se terminant le 19 sept)
Trustix 2
Sun 2
SuSE 2
OpenBSD 2
EnGarde 3
Mandrake 4
RedHat 4
Debian 7
-
[^]J'aime pas ces comparaisons
Posté par Brice Arnould ( un_brice ) (page perso, ) le 21/09/2003 à 12:22. (lien). Évalué à 1....
Quelles sont tes sources et quelles mèthodes as-tu utilisé pour obtenir ces données?
J'en profite pour pousser une gueulante: le nombre de failles n'aurais de sens que si on le ramenais au nombre de paquages.
Et encore: ça n'a pas de sens de compter tous les paquages (résultats absurdes genre 166failles/3333softs pour Debian et 30/50 pour m$win2k): il faudrait faire la somme des quantités de failles de l'OS et de ses programes, pondérées par les taux d'utilisation de ce derniers sur les serveurs et des niveaux de nuisibilités respectifs, en tenant compte de la rapidité de disponibilité du patch, voir de la probabilité que les pirates la connaissent depuis longtemps avant sa publication... on s'en sortiras pas.
D'ailleurs même des constats pratiques permettraient pas de comparer: le nombre d'attaques réussies dépend surtout du niveau de compètence de l'administrateur que de la sécurité intrinsèque de l'OS: tant qu'il applique les patchs, fait pas grosses co**eries, et à condition qu'il soit pas en charge du réseau d'une multinationale, il risque rien. Aussi bien sous GNU/Linux que *BSD ou winwin.
Donc à priori tout se vaut, sauf quand on commence à vouloir faire des trucs vraiment blindés (avec des fonctions de tueurs genre W^X sur x86, propolice, IPsec, firewalls de la mort, systrace, honeypots avec umL...) qui à ma connaissance ne sont supportés que sous Un*x (l'IPsec fourni avec win vaut rien à ce qu'on m'a dit (le firewall, j'en parle pas)).
Ça y est: j'ai fini de m'écouter parler. ^_^--
Respect à RMS.-
[^]Re: J'aime pas ces comparaisons
Posté par Wharf () le 22/09/2003 à 19:51. (lien). Évalué à 2.Tu as raison que ce type de comparaison peut etre source de polèmique indéfinies, mais les différences sont telles que personne ne peut nier que OpenBSD est le moins mauvais de la liste, que Microsoft n'est pas si mauvais, et que Mandrake ou Debian en cumulent beaucoup (trop): ont ils la structure pour assumer une telle taille de package ??.
Pas de gloriole, même les meilleurs de cette liste en ont trop !!!!
Pour plus de clarté je sépare différentes questions:
1/ Y a t il autant de bulletins que ca ?
va vérifier sur :
Debian : http://www.debian.org/security/(...)
Red Hat : http://www.redhat.com/apps/support/errata/(...)
Mandrake : http://www.mandrakesecure.net/en/advisories/(...)
SuSE : http://www.suse.com/de/security/announcements/index.html(...)
2/ Ces bulletins sont ils tous liès à la sécurité ?
Non, il y a aussi les vulnérabilitès critiques pour la stabilitè:
Donc pour détailler, voici un exemple pour 2 OS sortis à peu près à la même date: Windows 2003 Server ( sortie officielle le 24 avril) et Redhat 9 (sortie officielle le 30 mars) Dans les 2 cas, il y a parfois plus d'un correctif par bulletin.:
- Redhat9: pour la seule sécurité: https://rhn.redhat.com/errata/rh9-errata-security.html(...)
50 bulletins pour Redhat 9 ; si lon supprime les vulnérabilités liées à Pine et Sendmail, celle liée à Evolution et celle liée à MySQL, ca fait 44 vulnérabilités.
- Windows 2003 Server: il y a 19 corrections disponibles sous Windows Update. Je n'ai pas le détail, c'est un total "toutes corrections confondues": sécurité et toute autre correction critique.
3/ Peux t on comparer exactement tous ces chiffres ?
Non, car selon les éditeurs, ces bulletins ne recouvrent pas la même chose, de plus les OS ne comprennent pas les mêmes fonctionalitès, et en plus certains packages proposent des composants redondants entre eux:
4/ Tu as raison: le vrai pb est le délai de disponibilité du correctif
Patcher n'est pas la panacée, mais en attendant .... tout administrateur sérieux doit tout de même s'y atteler.
A mon avis, le pb est que si les corectifs de ces composants unitaires sont dispos dans des délais satisfaisants, le temps que les grandes distrib intégrent et valident officiellement ces correctifs dans leurs versions supportées est trop long.
Et le pb, c'est cette version "entreprise" payante et supportée qu'on utilise pour des applis critiques.
J'ai déjà vu des études de délai de disponibilitè des correctifs: il faut que je les retrouve....
le résultat était .. décevant !!
-




Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.