lundi 05 janvier
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

: Faille Sendmail et vulnérabilité OpenSSH

Posté par jr lamoule (page perso, ). Modéré le 18 septembre 2003.
0
Olivier HOUTE nous informe :
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.

> Lire la suite (73 commentaires, moyenne: 2,5).   [dépêche : 841 caractères]

Patch Sendmail :

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;
}

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.

Re: Faille sendmail et vulnérabilité OpenSSH

Posté par earxtacy (Jabber id, ) le 18/09/2003 à 07:41. (lien). Évalué à 11.

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 kapouik () le 18/09/2003 à 07:43. (lien). Évalué à 0.

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 à 07:46. (lien). Évalué à 5.

> 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 passant (page perso, ) le 18/09/2003 à 07:49. (lien). Évalué à 2.

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

Posté par FRLinux (page perso, ) le 18/09/2003 à 09:59. (lien). Évalué à 6.

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

Alternative à OpenSSH

Posté par bmc () le 18/09/2003 à 13:05. (lien). Évalué à 4.

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 ?

Une bien bonne sur Sendmail

Posté par Xavier Bestel (Jabber id, page perso, ) le 18/09/2003 à 19:20. (lien). Évalué à 1.

J'en ai entendu une bien bonne: "Sendmail has more exploitable holes than a parade of hookers" ... je traduirais pas :)

Buffers Overflows

Posté par ciskos () le 19/09/2003 à 18:23. (lien). Évalué à 2.

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: Faille Sendmail et vulnérabilité OpenSSH

Posté par ciskos () le 19/09/2003 à 18:28. (lien). Évalué à -1.

test because le précédent commentaire envoyé ne s'affiche pas

[+] Buffers Overflows

Posté par ciskos () le 20/09/2003 à 10:22. (lien). Évalué à -1.

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: L'année 2003 se termine mal !!

Posté par Wharf () le 20/09/2003 à 14:41. (lien). Évalué à 0.

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

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.34s (dont 0.1172 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !