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. 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;
}
Aller plus loin
- Site Sendmail (3 clics)
- Référence FullDisclosure (1 clic)
- Site officiel de OpenSSH (2 clics)
- Dépêche précédente sur la sortie de OpenSSH 3.7 (2 clics)
- L'alerte sur le site du CERT Coordination Center (3 clics)
# Re: Faille sendmail et vulnérabilité OpenSSH
Posté par earxtacy . Évalué à 10.
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 _ . Évalué à 6.
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par earxtacy . Évalué à 2.
scoré a -1 on se demande pourquoi
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par _PinG _ . Évalué à 10.
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
Posté par earxtacy . Évalué à 5.
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Misc (site web personnel) . Évalué à 4.
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 . Évalué à 2.
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
Posté par kapouik . Évalué à 0.
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Austin . Évalué à 5.
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 (site web personnel) . Évalué à 8.
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 . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par syntaxerror . Évalué à 5.
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 . Évalué à 3.
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 . Évalué à 4.
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
Posté par Austin . Évalué à 0.
Et c'est donné raison à l'argument de MS : Unix c'est vieux, donc c'est pourri.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 5.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par matli . Évalué à 3.
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par tipmeabout . Évalué à 2.
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 (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 1.
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 . Évalué à 1.
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par vjm . Évalué à 2.
# Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Austin . Évalué à 5.
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 (site web personnel) . Évalué à 2.
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par B. franck . Évalué à 2.
comme j'aurais aimé trouver un lien vers ces correctifs !
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Austin . Évalué à 5.
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 . Évalué à 2.
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Pierre Tramo (site web personnel) . Évalué à -1.
Même la Slackware ?
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par _PinG _ . Évalué à 3.
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 _ . Évalué à 2.
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
Posté par gosseyn . Évalué à -1.
Bon ok je sors ----> []
# Re: Faille sendmail et vulnérabilité OpenSSH
Posté par passant·e . Évalué à 2.
en route pour un update...
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: Faille sendmail et vulnérabilité OpenSSH
Posté par Éric (site web personnel) . Évalué à 7.
# Re: Faille sendmail
Posté par FRLinux (site web personnel) . Évalué à 6.
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 . Évalué à -1.
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 (site web personnel) . Évalué à 7.
Impact: System access
Where: From remote
# Alternative à OpenSSH
Posté par bmc . Évalué à 4.
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 (site web personnel) . Évalué à 0.
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 (site web personnel) . Évalué à 6.
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 . Évalué à 6.
http://www.lysator.liu.se/~nisse/lsh/(...)
mais je pense qu'openssh va finir par etre robuste.
[^] # Re: Alternative à OpenSSH
Posté par Gloo . Évalué à 0.
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 . Évalué à 1.
[^] # Re: Alternative à OpenSSH
Posté par Gloo . Évalué à 0.
openssh commence à entrer severement dans cette categorie.
[^] # Re: Alternative à OpenSSH
Posté par nocmahr . Évalué à 1.
J'ai beau chercher je ne trouve pas ... je dois mal chercher. Une suggestion ?
[^] # Re: Alternative à OpenSSH
Posté par bmc . Évalué à 1.
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 . Évalué à 2.
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
Posté par earxtacy . Évalué à 1.
(voir liste full-disclosure)
comme quoi faut pas tout mettre dans le meme panier.
Openssh n'est pas sendmail (longeur du code et feature).
[^] # Re: Alternative à OpenSSH
Posté par monsieurw . Évalué à 3.
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
Posté par monsieurw . Évalué à 1.
- Preliminary TCP forwarding support (-L style only)
[^] # Re: Alternative à OpenSSH
Posté par titi toto . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Alternative à OpenSSH
Posté par titi toto . Évalué à 2.
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 un_brice (site web personnel) . Évalué à 1.
emerge sync && emerge -uD world
[^] # Re: Alternative à OpenSSH
Posté par Gloo . Évalué à 1.
[^] # Re: Alternative à OpenSSH
Posté par Wawet76 (site web personnel) . Évalué à 3.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 2.
[^] # Re: Alternative à OpenSSH
Posté par snurpsss . Évalué à 0.
# Une bien bonne sur Sendmail
Posté par Xavier Bestel (site web personnel) . Évalué à 1.
[^] # Re: Une bien bonne sur Sendmail
Posté par imr . Évalué à 1.
"Sendmail a plus de trous exploitables qu'un défilé de politiciens".
Je sais, je sais ...
[^] # Re: Une bien bonne sur Sendmail
Posté par FRLinux (site web personnel) . Évalué à 1.
Steph
[^] # Re: Une bien bonne sur Sendmail
Posté par snurpsss . Évalué à 1.
--> []
[^] # Re: Une bien bonne sur Sendmail
Posté par imr . Évalué à 2.
ca veut dire "avocat spécialiste en propriété intellectuelle" en fait.
# Buffers Overflows
Posté par ciskos . Évalué à 2.
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 _ . Évalué à 1.
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
Posté par ciskos . Évalué à -1.
# Buffers Overflows
Posté par ciskos . Évalué à -1.
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
Posté par ciskos . Évalué à 1.
# Re: L'année 2003 se termine mal !!
Posté par Wharf . Évalué à 0.
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 un_brice (site web personnel) . É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. ^_^
[^] # Re: J'aime pas ces comparaisons
Posté par Wharf . Évalué à 2.
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 !!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.