En fait la publication des sources ne protège des trous de securité que
si ceux qui publient les sources vérifient bien tous les ajouts (et encore
certains trous ne sont simplement que des bugs qui ne sont pas toujours
évidents).
En plus la personne qui fait ce genre de modification doit être connue.
Je ne connais personne qui relise tout le code pour voir s'il y a
quelquechose de louche dedans avant la compilation.
Par contre avec l'accès aux sources une faillle detecté il est aisé de
trouver où comment et parfois par qui elle a été introduite.
Et on peut aussi voir si elle a été introduite par erreur ou volontairement.
Dans le cas d'irssi la personne qui a modifié les sources n 'est
évidemment pas passée par le mécanisme classique de soumission de patche
ou par CVS.
En plus le trou est réalisé en quelques lignes de code C, perdu dans les
lignes de C introduites dans le configure pour la detection du support de
fonctionnalités par le compilo...
Le plus fort c'est que ce trou effectue une connection directe à une adresse
IP codée en dur dans le fichier !
C'est assez gros, ce serait intéressant de savoir à qui appartient cette
adresse. Ce n'est évidemment pas forcément celui qui a introduit le code.
C'est peut-être juste une opération de discrédit.
Et c'est pourquoi la signature des fichiers est très importante, toute
alteration du contenu pourra etre detecté par l'utilisateur.
Encore faut-il que celui-ci prenne la peine de faire la vérification !
Imaginons maintenant que quelqu'un fasse ce genre de malversation
directement au niveau d'autoconf de la machine de compilation ou pire
encore des sources d'autoconf !
Et donc c'est l'utilisateur d'autoconf qui virus son propre config
(génèré a partir de config.in).
Le virus est introduit alors directement par la personne qui prépare
le package et il sera checksumé, signé et tout et tout !
Tout système de sécurite aussi perfectionné qu'il soit repose un moment
ou l'autre sur de l'humain.
# On pourrait imaginer pire.
Posté par philippe lhardy (site web personnel, Mastodon) . En réponse à la dépêche Backdoor dans irssi. Évalué à 10.
si ceux qui publient les sources vérifient bien tous les ajouts (et encore
certains trous ne sont simplement que des bugs qui ne sont pas toujours
évidents).
En plus la personne qui fait ce genre de modification doit être connue.
Je ne connais personne qui relise tout le code pour voir s'il y a
quelquechose de louche dedans avant la compilation.
Par contre avec l'accès aux sources une faillle detecté il est aisé de
trouver où comment et parfois par qui elle a été introduite.
Et on peut aussi voir si elle a été introduite par erreur ou volontairement.
Dans le cas d'irssi la personne qui a modifié les sources n 'est
évidemment pas passée par le mécanisme classique de soumission de patche
ou par CVS.
En plus le trou est réalisé en quelques lignes de code C, perdu dans les
lignes de C introduites dans le configure pour la detection du support de
fonctionnalités par le compilo...
Le plus fort c'est que ce trou effectue une connection directe à une adresse
IP codée en dur dans le fichier !
C'est assez gros, ce serait intéressant de savoir à qui appartient cette
adresse. Ce n'est évidemment pas forcément celui qui a introduit le code.
C'est peut-être juste une opération de discrédit.
Et c'est pourquoi la signature des fichiers est très importante, toute
alteration du contenu pourra etre detecté par l'utilisateur.
Encore faut-il que celui-ci prenne la peine de faire la vérification !
Imaginons maintenant que quelqu'un fasse ce genre de malversation
directement au niveau d'autoconf de la machine de compilation ou pire
encore des sources d'autoconf !
Et donc c'est l'utilisateur d'autoconf qui virus son propre config
(génèré a partir de config.in).
Le virus est introduit alors directement par la personne qui prépare
le package et il sera checksumé, signé et tout et tout !
Tout système de sécurite aussi perfectionné qu'il soit repose un moment
ou l'autre sur de l'humain.