Pour bosser dans le domaine, je peux te dire que c'est loin d'etre vrai.
C'est facile de voir un code et se dire "ben il suffit de changer xyz".
Le probleme, c'est qu'apres:
- il faut verifier(revue de code/design) que ton changement il ne casse rien, et ca prend du temps dans certains cas.
- il faut chercher et trouver les variantes de la faille originale, ca demande de faires des revues de code/design, du fuzzing, ... ca prend du temps (parce que si tu sors ton patch sans corriger les variantes, t'es bon pour des 0-days a la pelle)
- il faut tester le patch, ca prend du temps, enormement de temps
[^] # Re: SIGTROLL
Posté par pasBill pasGates . En réponse au journal Évaluation des risques de RHEL 4. Évalué à 4.
C'est facile de voir un code et se dire "ben il suffit de changer xyz".
Le probleme, c'est qu'apres:
- il faut verifier(revue de code/design) que ton changement il ne casse rien, et ca prend du temps dans certains cas.
- il faut chercher et trouver les variantes de la faille originale, ca demande de faires des revues de code/design, du fuzzing, ... ca prend du temps (parce que si tu sors ton patch sans corriger les variantes, t'es bon pour des 0-days a la pelle)
- il faut tester le patch, ca prend du temps, enormement de temps