J'ai eu l'occasion de me plonger dans une particularité de Java, la signature de code des applets. Je croyais que les applets ne pouvaient faire que des effets graphiques, et ne s'exécutaient que dans un bac à sable...
Je me suis penché sur les nouvelles fonctionnalités offertes : j'ai même fait une petite démo, c'est assez amusant :
http://davidferaoun.free.fr/eric/java/signed-fr.php
Notes:
- Pour qu'elle fonctionne, il faut que vous acceptez l'applet
- L'applet est inoffensive
Quelqu'un a-t-il la réponse à la dernière question sous l'applet, à savoir : les applets signées et certifiées par des organismes de certification demandent-elles toujours l'avis de l'internaute avant de s'exécuter ? Cela me semblerait très choquant qu'il suffise de quelques centaines de dollars pour pouvoir accéder aux disques durs des internautes...
Je trouve de toutes façons le message d'avertissement pas assez clair.
Journal Et vous, connaissez-vous la signature de code java ?
16
août
2006
# Pas seulement quelques centaines de dollars
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Quelqu'un qui signe une applet 'malintentionnée' met donc tout le monde au courant de son identité via la signature. Pas très discret...
[^] # Re: Pas seulement quelques centaines de dollars
Posté par eric . Évalué à 1.
Et puis si la personne (éventuellement morale) mal intentionnée est dans un pays avec peu de législation ? Ca lui est peut etre égal d'être peu discret ?
[^] # Re: Pas seulement quelques centaines de dollars
Posté par jeje99 . Évalué à 1.
[^] # Re: Pas seulement quelques centaines de dollars
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Est-ce vraiment une solution technique qu'il faut ou éduquer les utilisateurs ?
[^] # Re: Pas seulement quelques centaines de dollars
Posté par Olivier Serve (site web personnel) . Évalué à 1.
# re
Posté par kraman . Évalué à 1.
Elle indique que l'autorite est de confiance nia nia nia, mais demande quand meme si elle peut s'executer.
Je trouve de toutes façons le message d'avertissement pas assez clair.
bopf.
il ne sera de toutes facons jamais assez clair : soit la personne de quoi il s'agit et le message est clair, soit elle ne sait pas et le message n'est pas clair.
quoiqu'il arrive, le probleme est entre le clavier et la chaise, je vois pas vraiment comment tu peux autoriser une appli a s'executer sans le demander a l'utilisateur.
[^] # Re: re
Posté par ondex . Évalué à 3.
"Le programme win32_toto.exe tente d'accéder à l'ordinateur distant 56.96.128.173 sur le port 12569 en utilisant le port local 28965. Souhaitez vous autoriser cette opération ? : [OUI] [NON]" *
À ton avis, Mme Michu, elle pense quoi dans cette situation ? Un utilisateur lambda ne devrait pas être ammenné à prendre ce genre de décision car il n'y connait rien. Dans cette exemple, win32_toto.exe peut avoir l'air légitime tout en étant un cheval de Troie.
C'est facile de toujours invoquer "l'interface chaise - clavier" pour tenter de justifier les problèmes de conception des OS.
Si on pousse le raisonnement, on peut dire que quelqu'un qui met les doigts dans une prise est débile et puis c'est tout. Néanmoins, on prévoit le cas en protégeant les prises électriques. Nos OS devraient aussi prévoir le cas ou l'utilisateur est "débile" (comme les 3/4 des utlisateurs d'ordinateurs dans le monde).
* Cet exemple est tiré d'une conférence sur la sécurité des OS. La vidéo est disponible sur internet, le nom du fichier est "wth_client_security_is_wrong_96.mp4"
[^] # Re: re
Posté par kraman . Évalué à -2.
tout sand boxer?
pas possible, ca sert plus a rien d'avoir des applets.
laisser l'acces aux donnees?
ah ouais, mais c'est ca qu'il faut proteger.
[^] # Re: re
Posté par eric . Évalué à 1.
y'a plein de solutions :
- faire de meilleurs messages d'avertissements (le message actuel n'est pas clair du tout)
- faire différents niveaux de sandboxing (faire un client IRC est moins sensible que de lire/écrire dans les fichiers locaux)
- prévenir l'utilisateur systématiquement qd une applet tente d'acceder aux fichiers locaux (hors répertoire tmp)
[^] # Re: re
Posté par kraman . Évalué à 1.
2) ok, donc on garde le fonctionnement actuel sans rien changer,
3) ok, donc on garde le fonctionnement actuel en changeant juste la frequence des messages.
Ce a quoi l'utilisateur non averti repondra "oui, arrete de me faire chier".
C'est ce qui etait tres clairement explique dans la conf citee plus haut.
Maintenant, si t'as une autre voie qui :
1) permette d'executer une application distante tierce quelconque qui manipule les donnees utilisateur,
2) garantisse l'integrite des donnees utilisateur,
3) le tout sans aucune intervention humaine,
vas y on t'ecoute tous.
[^] # Re: re
Posté par kraman . Évalué à 4.
ce qui m'a le plus choqué, c'est que du jour au lendemain, les applets, connues pour ne rien pouvoir faire
???
les applets signees, ca a toujours existe... C'est meme un peu le concept de l'applet...
http://java.sun.com/developer/technicalArticles/Security/Sig(...)
ca date de 98...
[^] # Re: re
Posté par Nicolas Schoonbroodt . Évalué à 5.
[^] # Re: re
Posté par eric . Évalué à 1.
[^] # Re: re
Posté par pasBill pasGates . Évalué à 2.
T'as mieux a proposer pour empecher un soft quelconque d'ouvrire un port ?
[^] # Re: re
Posté par ondex . Évalué à 2.
En réalité, quelles sont les applications qui ont réèllement besoin d'accéder aux réseaux ? C'est assez limité : navigateur, mua, flux RSS, navigateur de fichier (et encore, de façon spécifique), FTP, IRC, IM (ok, ça commence à faire beaucoup)
Les autres n'en ont pas besoin. Pour les applications qui vérifie elle-même leur mise à jour, elles devront s'en passer. Les mises à jour doivent être gérer de manière centralisée par l'OS (un peu à la apt-get). Souvent on rétorque qu'avec des applications propriétaire ce n'est pas possible => faux, il suffit d'avoir un dépot par application et laisser l'OS gérer les mises à jour.
Donc, à mon avis, par défaut une application ne devrait pas être autorisée à accéder à un réseau.
Toute la difficulté se situe dans le choix des applications qui peuvent y accéder.
Une idée peut être => une sorte de proxy logiciel (au niveau de l'OS) qui contrôle les transferts des protocoles classique (HTTP, IMAP, SMTP, IRC) et interrompts tout ce qui est louche
Chaque fois qu'une application tente d'établir une connexion, le "proxy" analyse et stoppe si c'est un port exotique ou si les données ne correspondent pas à ce qu'on attend (pour ceux qui font du tunneling HTTP)
PS : désolé si c'est un peu décousu mais je tape ça comme ça me viens
[^] # Re: re
Posté par pasBill pasGates . Évalué à 2.
Oh mais il y a bcp plus que ca, OpenOffice par exemple peut downloader des dicos, ... depuis le web, des editeurs HTML peuvent sauver sur des serveurs web/ftp, nombre de softs professionels vont acceder a des bases de donnees, les jeux en reseau, ...
Chaque fois qu'une application tente d'établir une connexion, le "proxy" analyse et stoppe si c'est un port exotique ou si les données ne correspondent pas à ce qu'on attend (pour ceux qui font du tunneling HTTP)
Et tu fais quoi par exemple pour les jeux qui tres souvent utilisent leur propre protocole ? Tu vas empecher les gens de jouer ?
Bref, le probleme est tres tres loin d'etre simple a resoudre, et la methode existante n'est au fond pas si mal vu les contraintes.
[^] # Re: re
Posté par ondex . Évalué à 2.
Ce type d'opération devrait être géré par l'OS. Un dictionnaire est un paquet présent sur le dépot du logiciel.
Ce type d'opération serait surveillée par le "proxy" de l'OS.
Evidement, pour qu'un malware n'upload pas tous nos fichiers sur un serveur via un protocole légitime (FTP par exemple) il faut une autre couche de sécurité (une cage par application ?)
Reste effectivement le problème des protocoles propriétaires. Je ne vois pas d'autre solution qu'une liste d'exceptions gérable par l'utilisateur. Dans le cas des applications professionnelles, l'admin réseau de la société se charge de mettre la-dite application dans une liste d'exception. Pour les jeux, l'utilisateur devra paramétrer un peu sa machine (c'est pas forcement plus compliqué que de répondre à la super question du parefeux)
Effectivement, gérer une politique de sécurité fiable sans être trop contraignante est très compliqué, je ne prétends aucunement apporter LA solution, j'expose juste mes idées.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.