J'ai donné ces derniers jours quelques exploitations de mémoires.
C'est fait de manière artisanale, avec gdb et une calculette hexa, mais tout le monde sait qu'il existe de meilleurs outils (ida, metasploit, d'autres?). Ces exploitations sont très simples, car il n'y a aucune protection sur l'OS ou le binaire. Ces protections n'empêchent pas l'exploitation, à chaque fois les attaquants réussissent à contourner ces barrières. Est-ce que la bataille est perdue?
J'ai lu un article de blog intéressant, indiquant la lassitude d'un hacker à se promener dans la mémoire pour réussir à obtenir un exploit fiable. Il parle de plusieurs semaines (mois) de recherche pour obtenir un exploit correct. La solution passe peut-être par là. La durée de vie trop longue semble une donnée importante. L'exemple de windowsXP est marquant. Nous avons une génération de pirates qui a pu passé 10 ans sur un système. Avec le release early release often popularisé par linux, le temps nécessaire à attaquer est supérieur à la durée de vie d'une release. Un second exemple vient d'une grosse société pour qui j'ai travaillé. La validation des socles (hardware, OS, BdD, logiciels) prenait plusieurs années. Une fois le socle validé, aucun changement ou patch n'est autorisé. D'un certain côté on gagne en sécurité de fonctionnement (la reliability) puisque le socle est _parfaitement_ connu, d'un autre on perd en sécurité (les failles) puisque le socle ne sera jamais patché. [Dans le cas présent, les machines n'étaient pas sur un réseau connecté à internet, mais je ne suis pas partisan de cette manière de faire]. Un pirate pourrait forger son exploit pendant des années avant de le lancer.
La durée d'utilisation d'un programme correctement protégé semble être une faille en soi. Nous avons donc d'un côté des binaires de plus en plus difficile à exploiter, et de l'autre des méthodes de rolling releases émergent comme Chrome ou firefox. Comment exploiter une faille si le programme attaqué change plusieurs fois par mois? Je n'ai pas vérifié, mais si chrome n'est pas attaqué dans les pwn2own, c'est qu'il est si solide que ça ou qu'il change trop fréquemment pour qu'on s'intéresse à l'attaquer?
Pour l'administrateur, c'est simple, c'est du patch management, et le patch management, ça fait bien depuis 2003 que c'est une technique maîtrisée.
L'immobilité pour les systèmes, c'est la mort assurée. La course en avant vers les versions toujours plus à jour serait une solution? Après le SDL, le release early release often pour l'ensemble du système d'information?
Le problème se pose quant aux systèmes critiques. Je ne me sentirai pas rassuré si la tonne de firmware de l'avion que je prend change tous les 6 mois.
RépondreSupprimerEt puis l'ajout de fonctionnalité serais un obstacle majeur pour le particulier. pour l'exemple, j'ai configuré une ubuntu pour un membre de la famille d'une cinquantaine d'année. l'ubuntu n'avais pas unity. Mon conseil à toujours été de faire les mises à jour et lors du passage à la 11.10 paf, unity est venu se réinstaller, et j'ai eu droit à un coup de téléphone pour régler le soucis (étant à 900km de là, ça a pas été tout ce qu'il y a de plus simple).
Et puis ça serais l'abandon de la sécurité, il deviendrait inutile de creuser le sujet car même si le système est troué, ça restera pas longtemps.
je suis pas fan :)