ho le jolie PEBKAC. Quand une équipe de dev ne veut pas résoudre ses bugs, là on dépasse le niveau du PEBKAC, ça devient de l'idiotie suprême.
Réglons le problème à la source, flinguons les.

t'as une url de bugzilla, ou de forum, ... ?

A part planter le programme en cours, un segfault peut t'il modifier d'autres données? par exemple, en écrivant à une autre adresse?

Après comme dirait mon ancien prof de maths : MIMO, Merde In, Merde Out

Si le processus en qui a fait la segfault modifiait d'autres données, celles-ci peuvent être corrompues.

C'est comme pour les ceintures de sécurité: c'est pas la peine d'en mettre, il n'y a qu'à pas avoir d'accident!

En faisant un cookie malformé "au bol", y'a peu de chance. Maintenant, en faisant un cookie malformé dans le but d'exploiter la faille, y'a plein de trucs sympas à faire ;)

Tu peux aussi lui dire "t'as qu'à pas répondre des phrases de m*rde" pour qu'il évite de recevoir un coup de ton pied dans ses c*illes !

(Lisez ceci avec la voix de Daniel Prevost)
- Heu, Bernard, comment on faut pour un joint de culasse pété ?
- Ben tu le remplaces par un joint de culasse qu'est pas pété

"Je signale le problème à l'équipe de développement, et leur demande comment mitiger le problème."

"comment régler le problème" éventuellement ... "mitiger le problème" ça fait juste la grosse tâche qui traduit à coups de Google trad ...

<HS>
Bonjour à tous. Je m'adresse à vous car je me suis lancé dans l'auto-hébergement d'un site internet sur un Raspberry Pi (www.raspberrypi.org/faqs pour ceux qui connaissent pas) configuré en serveur web, et j'ai besoin d'aide pour tester sa robustesse. (attention pas de tentative de hack, je veux juste savoir à combien de connexions il crash)
Alors pour ceux qui veulent bien et qui n'ont rien prévu de mieux samedi à 17h, vous pouvez venir à l'adresse http://rpi.informotics.fr (et vous aurez un cookie).
Merci et désolé pour le HS.
</HS>

Cadeau :
https://fr.wikipedia.org/wiki/Attaque_par_d%C3%A9ni_de_service#Outils

while true ; do wget -O /dev/null rpi.informotics.fr & done

Non, pas forcément...

Dans le monde réel, il n'est pas toujours possible de corriger les problèmes rapidement et de façon satisfaisante. C'est comme ça.

Par contre, il existe peut-être une solution rapide pour contourner le problème. Je pense par exemple à l'adaptation des filtres qui existent certainement déjà sur le réseau pour bloquer le motif qui déclenche la faille. Le problème n'est pas corrigé, mais les risques sont très fortement réduits.

Note, une des déifnitions de mitiger selon le TLFi est :
Rendre quelque chose moins pénible, moins douloureux pour quelqu'un.

C'est le principe même des attaques par buffer overflow...

Never trust user input n'est pas un vain concept.

Les images sont longues à charger, c'est hébergé chez toi avec un débit digne du Cantal? Si oui ta connexion va rendre l'âme avant le raspberry...

@Freudo : tache*, merci.

Ah oui effectivement ma connexion est assez lente. Bah on verra bien, au pire c'est pas très grave si ça met longtemps à charger xD

Acné l'a bien compris, il n'était pas question de mettre en production du code corrigé a l'arrache, donc par mitiger j'entendais bien diminuer l'impact de la faille, par des changements de configuration, quitte a sacrifier les fonctionnalités ou la performance, en attendant qu'ils puissent tester une vraie solution.

Et non je ne filerai pas d'URL ni de noms, mais si vous pensez savoir de quelle institution il s'agit, ils ont sorti le 15 octobre une nouvelle version de leur module qui corrige (entre autres) un déréférencement de pointeur nul. Et sans nous créditer, ces salauds.

PS: editorial fail, c'est l'école entière qui compte 8k étudiants, pas la fac d'informatique.

microsoft fait du module apache maintenant ???

Finalement, Aaargh !!! reste plutôt modéré à ne proposer que des baffes.

Surtout qu'il me semble qu'il existe déjà un module équivalent open source.
Mais j'ai parfois l'impression que certaines personnes réinventent la roue en moins rond ;)