Pour la première fois aujourd'hui, j'ai installé sur mon PC
(MS-Windows 2000) un programme fait en Java, appelé à communiquer avec
Internet sur de longues périodes. Et j'ai eu la désagréable surprise
de m'apercevoir que, contrairement par exemple à un programme Python,
il n'est pas encapsulé dans un .exe, mais s'appelle via
l'interpréteur, Javaw.exe. Ce qui fait que j'ai dû autoriser (dans la
config de Kerio) ce javaw.exe à communiquer avec l'extérieur.
Ça me paraît une faille de sécurité : n'importe quel troyen écrit en
Java va donc pouvoir expédier ses données comme bon lui semble.
Qu'en pensez-vous ? Y a-t-il un moyen de contourner le problème ?
effectivement la programme java s'exécute dans la JVM. LA configuration sécurité de la JVM est paramétrable par la politique de CQ spécifique. Il me semble possible d'associer des droits particuliers à des applets connue (par leur signature) et de mettre en oeuvre des bloquages en cas de signatures non valides. Codialement.
Fabien LE LEZ wrote:
Bonjour,
Pour la première fois aujourd'hui, j'ai installé sur mon PC (MS-Windows 2000) un programme fait en Java, appelé à communiquer avec Internet sur de longues périodes. Et j'ai eu la désagréable surprise de m'apercevoir que, contrairement par exemple à un programme Python, il n'est pas encapsulé dans un .exe, mais s'appelle via l'interpréteur, Javaw.exe. Ce qui fait que j'ai dû autoriser (dans la config de Kerio) ce javaw.exe à communiquer avec l'extérieur. Ça me paraît une faille de sécurité : n'importe quel troyen écrit en Java va donc pouvoir expédier ses données comme bon lui semble.
Qu'en pensez-vous ? Y a-t-il un moyen de contourner le problème ?
Merci d'avance.
Bonjour,
effectivement la programme java s'exécute dans la JVM. LA configuration
sécurité de la JVM est paramétrable par la politique de CQ spécifique. Il
me semble possible d'associer des droits particuliers à des applets connue
(par leur signature) et de mettre en oeuvre des bloquages en cas de
signatures non valides.
Codialement.
Fabien LE LEZ wrote:
Bonjour,
Pour la première fois aujourd'hui, j'ai installé sur mon PC
(MS-Windows 2000) un programme fait en Java, appelé à communiquer avec
Internet sur de longues périodes. Et j'ai eu la désagréable surprise
de m'apercevoir que, contrairement par exemple à un programme Python,
il n'est pas encapsulé dans un .exe, mais s'appelle via
l'interpréteur, Javaw.exe. Ce qui fait que j'ai dû autoriser (dans la
config de Kerio) ce javaw.exe à communiquer avec l'extérieur.
Ça me paraît une faille de sécurité : n'importe quel troyen écrit en
Java va donc pouvoir expédier ses données comme bon lui semble.
Qu'en pensez-vous ? Y a-t-il un moyen de contourner le problème ?
effectivement la programme java s'exécute dans la JVM. LA configuration sécurité de la JVM est paramétrable par la politique de CQ spécifique. Il me semble possible d'associer des droits particuliers à des applets connue (par leur signature) et de mettre en oeuvre des bloquages en cas de signatures non valides. Codialement.
Fabien LE LEZ wrote:
Bonjour,
Pour la première fois aujourd'hui, j'ai installé sur mon PC (MS-Windows 2000) un programme fait en Java, appelé à communiquer avec Internet sur de longues périodes. Et j'ai eu la désagréable surprise de m'apercevoir que, contrairement par exemple à un programme Python, il n'est pas encapsulé dans un .exe, mais s'appelle via l'interpréteur, Javaw.exe. Ce qui fait que j'ai dû autoriser (dans la config de Kerio) ce javaw.exe à communiquer avec l'extérieur. Ça me paraît une faille de sécurité : n'importe quel troyen écrit en Java va donc pouvoir expédier ses données comme bon lui semble.
Qu'en pensez-vous ? Y a-t-il un moyen de contourner le problème ?
Merci d'avance.
Jean Gab1
| Pour la première fois aujourd'hui, j'ai installé sur mon PC | (MS-Windows 2000) un programme fait en Java, appelé à communiquer avec | Internet sur de longues périodes. Et j'ai eu la désagréable surprise | de m'apercevoir que, contrairement par exemple à un programme Python, | il n'est pas encapsulé dans un .exe, mais s'appelle via | l'interpréteur, Javaw.exe. Ce qui fait que j'ai dû autoriser (dans la | config de Kerio) ce javaw.exe à communiquer avec l'extérieur. | Ça me paraît une faille de sécurité : n'importe quel troyen écrit en | Java va donc pouvoir expédier ses données comme bon lui semble. | | Qu'en pensez-vous ? Y a-t-il un moyen de contourner le problème ?
sous unix, tu fais juste un petit script shell qui appelle java avec ton jar, cela te permettras de ne pas controler javaw.exe. (sous windows, cela doit être pareille, un fichier .bat)
ensuite tu controle uniquement ton script shell, et pas la peine d'autoriser javaw.exe :) mais juste ton script (cela réduit le risque, mais n'est pas parfait...)
A+
| Pour la première fois aujourd'hui, j'ai installé sur mon PC
| (MS-Windows 2000) un programme fait en Java, appelé à communiquer avec
| Internet sur de longues périodes. Et j'ai eu la désagréable surprise
| de m'apercevoir que, contrairement par exemple à un programme Python,
| il n'est pas encapsulé dans un .exe, mais s'appelle via
| l'interpréteur, Javaw.exe. Ce qui fait que j'ai dû autoriser (dans la
| config de Kerio) ce javaw.exe à communiquer avec l'extérieur.
| Ça me paraît une faille de sécurité : n'importe quel troyen écrit en
| Java va donc pouvoir expédier ses données comme bon lui semble.
|
| Qu'en pensez-vous ? Y a-t-il un moyen de contourner le problème ?
sous unix, tu fais juste un petit script shell qui appelle java avec ton
jar, cela te permettras de ne pas controler javaw.exe. (sous windows, cela
doit être pareille, un fichier .bat)
ensuite tu controle uniquement ton script shell, et pas la peine d'autoriser
javaw.exe :) mais juste ton script (cela réduit le risque, mais n'est pas
parfait...)
| Pour la première fois aujourd'hui, j'ai installé sur mon PC | (MS-Windows 2000) un programme fait en Java, appelé à communiquer avec | Internet sur de longues périodes. Et j'ai eu la désagréable surprise | de m'apercevoir que, contrairement par exemple à un programme Python, | il n'est pas encapsulé dans un .exe, mais s'appelle via | l'interpréteur, Javaw.exe. Ce qui fait que j'ai dû autoriser (dans la | config de Kerio) ce javaw.exe à communiquer avec l'extérieur. | Ça me paraît une faille de sécurité : n'importe quel troyen écrit en | Java va donc pouvoir expédier ses données comme bon lui semble. | | Qu'en pensez-vous ? Y a-t-il un moyen de contourner le problème ?
sous unix, tu fais juste un petit script shell qui appelle java avec ton jar, cela te permettras de ne pas controler javaw.exe. (sous windows, cela doit être pareille, un fichier .bat)
ensuite tu controle uniquement ton script shell, et pas la peine d'autoriser javaw.exe :) mais juste ton script (cela réduit le risque, mais n'est pas parfait...)
A+
Marwan Burelle
On 01 Feb 2004 09:51:37 GMT Fabien LE LEZ wrote:
Pour la première fois aujourd'hui, j'ai installé sur mon PC (MS-Windows 2000) un programme fait en Java, appelé à communiquer avec Internet sur de longues périodes. Et j'ai eu la désagréable surprise de m'apercevoir que, contrairement par exemple à un programme Python, il n'est pas encapsulé dans un .exe, mais s'appelle via l'interpréteur, Javaw.exe. Ce qui fait que j'ai dû autoriser (dans la config de Kerio) ce javaw.exe à communiquer avec l'extérieur. Ça me paraît une faille de sécurité : n'importe quel troyen écrit en Java va donc pouvoir expédier ses données comme bon lui semble.
Il y a une certaine politique de sécurité pour éviter ce genre de problème.
Globalement, l'idée est de ne pas laissé les applets faire n'importe quoi (que ce soit côté file system ou côté connexion réseau.)
La politique par défaut (de la jvm de sun, en tout cas de ses spécifications mais à priori Sun les respecte, après je ne sais pas) est de laisser aux applets que la possibilité de communiquer avec leur serveur d'origine (ce qui évite les applets destinées à contourner les firewall.)
Après, lorsque l'on sort des applets, c'est un peu plus compliqué et surtout plus tendancieux.
Pour ceux que ça intéresse, il y a un papier sur les Secure Safe Ambients de Giuseppe Castagna et Michele Bugliesi qui fournit une méthode (théorique) pour lutter contre ce genre de problèmes. Cette méthode correspond dans une certaines mesures à ce qui est fait dans la jvm (c'est aussi dans le papier.)
(la page de référence du papier sur Citeseer : http://citeseer.nj.nec.com/bugliesi01secure.html pour la version journal
http://citeseer.nj.nec.com/bugliesi00secure.html pour l'extended abstract)
Maintenant, tout ça signifie que vous faîtes confiance dans l'implantation de votre jvm.
On 01 Feb 2004 09:51:37 GMT
Fabien LE LEZ <gramster@gramster.com> wrote:
Pour la première fois aujourd'hui, j'ai installé sur mon PC
(MS-Windows 2000) un programme fait en Java, appelé à communiquer avec
Internet sur de longues périodes. Et j'ai eu la désagréable surprise
de m'apercevoir que, contrairement par exemple à un programme Python,
il n'est pas encapsulé dans un .exe, mais s'appelle via
l'interpréteur, Javaw.exe. Ce qui fait que j'ai dû autoriser (dans la
config de Kerio) ce javaw.exe à communiquer avec l'extérieur.
Ça me paraît une faille de sécurité : n'importe quel troyen écrit en
Java va donc pouvoir expédier ses données comme bon lui semble.
Il y a une certaine politique de sécurité pour éviter ce genre de
problème.
Globalement, l'idée est de ne pas laissé les applets faire n'importe quoi
(que ce soit côté file system ou côté connexion réseau.)
La politique par défaut (de la jvm de sun, en tout cas de ses
spécifications mais à priori Sun les respecte, après je ne sais pas) est
de laisser aux applets que la possibilité de communiquer avec leur serveur
d'origine (ce qui évite les applets destinées à contourner les firewall.)
Après, lorsque l'on sort des applets, c'est un peu plus compliqué et
surtout plus tendancieux.
Pour ceux que ça intéresse, il y a un papier sur les Secure Safe Ambients
de Giuseppe Castagna et Michele Bugliesi qui fournit une méthode
(théorique) pour lutter contre ce genre de problèmes. Cette méthode
correspond dans une certaines mesures à ce qui est fait dans la jvm (c'est
aussi dans le papier.)
(la page de référence du papier sur Citeseer :
http://citeseer.nj.nec.com/bugliesi01secure.html pour la version journal
http://citeseer.nj.nec.com/bugliesi00secure.html pour l'extended abstract)
Maintenant, tout ça signifie que vous faîtes confiance dans l'implantation
de votre jvm.
Pour la première fois aujourd'hui, j'ai installé sur mon PC (MS-Windows 2000) un programme fait en Java, appelé à communiquer avec Internet sur de longues périodes. Et j'ai eu la désagréable surprise de m'apercevoir que, contrairement par exemple à un programme Python, il n'est pas encapsulé dans un .exe, mais s'appelle via l'interpréteur, Javaw.exe. Ce qui fait que j'ai dû autoriser (dans la config de Kerio) ce javaw.exe à communiquer avec l'extérieur. Ça me paraît une faille de sécurité : n'importe quel troyen écrit en Java va donc pouvoir expédier ses données comme bon lui semble.
Il y a une certaine politique de sécurité pour éviter ce genre de problème.
Globalement, l'idée est de ne pas laissé les applets faire n'importe quoi (que ce soit côté file system ou côté connexion réseau.)
La politique par défaut (de la jvm de sun, en tout cas de ses spécifications mais à priori Sun les respecte, après je ne sais pas) est de laisser aux applets que la possibilité de communiquer avec leur serveur d'origine (ce qui évite les applets destinées à contourner les firewall.)
Après, lorsque l'on sort des applets, c'est un peu plus compliqué et surtout plus tendancieux.
Pour ceux que ça intéresse, il y a un papier sur les Secure Safe Ambients de Giuseppe Castagna et Michele Bugliesi qui fournit une méthode (théorique) pour lutter contre ce genre de problèmes. Cette méthode correspond dans une certaines mesures à ce qui est fait dans la jvm (c'est aussi dans le papier.)
(la page de référence du papier sur Citeseer : http://citeseer.nj.nec.com/bugliesi01secure.html pour la version journal
http://citeseer.nj.nec.com/bugliesi00secure.html pour l'extended abstract)
Maintenant, tout ça signifie que vous faîtes confiance dans l'implantation de votre jvm.
On 03 Feb 2004 01:26:42 GMT, Marwan Burelle wrote:
Après, lorsque l'on sort des applets, c'est un peu plus compliqué et surtout plus tendancieux.
Je confirme qu'il ne s'agit pas d'une applet, mais bien d'un logiciel totalement indépendant d'un navigateur. J'avais entendu des rumeurs prétendant qu'il existait effectivement des applications écrites en Java, et je viens d'en découvrir une :-/
-- ;-)
On 03 Feb 2004 01:26:42 GMT, Marwan Burelle <burelle@lri.fr> wrote:
Après, lorsque l'on sort des applets, c'est un peu plus compliqué et
surtout plus tendancieux.
Je confirme qu'il ne s'agit pas d'une applet, mais bien d'un logiciel
totalement indépendant d'un navigateur. J'avais entendu des rumeurs
prétendant qu'il existait effectivement des applications écrites en
Java, et je viens d'en découvrir une :-/
On 03 Feb 2004 01:26:42 GMT, Marwan Burelle wrote:
Après, lorsque l'on sort des applets, c'est un peu plus compliqué et surtout plus tendancieux.
Je confirme qu'il ne s'agit pas d'une applet, mais bien d'un logiciel totalement indépendant d'un navigateur. J'avais entendu des rumeurs prétendant qu'il existait effectivement des applications écrites en Java, et je viens d'en découvrir une :-/
-- ;-)
Fabien LE LEZ
On 02 Feb 2004 20:45:28 GMT, "Jean Gab1" <"."@> wrote:
sous unix, tu fais juste un petit script shell qui appelle java avec ton jar, cela te permettras de ne pas controler javaw.exe.
(sous windows, cela doit être pareille, un fichier .bat)
Non, sous Windows ça ne marche pas : il n'y a pas de notion de processus père/fils -- cmd.exe va lire le .bat, et lancer javaw.exe qui va alors être totalement indépendant, même s'il est possible que cmd.exe attende qu'il ait fini pour continuer à lire le .bat. Du coup c'est bien javaw.exe qui va chercher à sortir :-(
-- ;-)
On 02 Feb 2004 20:45:28 GMT, "Jean Gab1" <"."@> wrote:
sous unix, tu fais juste un petit script shell qui appelle java avec ton
jar, cela te permettras de ne pas controler javaw.exe.
(sous windows, cela doit être pareille, un fichier .bat)
Non, sous Windows ça ne marche pas : il n'y a pas de notion de
processus père/fils -- cmd.exe va lire le .bat, et lancer javaw.exe
qui va alors être totalement indépendant, même s'il est possible que
cmd.exe attende qu'il ait fini pour continuer à lire le .bat.
Du coup c'est bien javaw.exe qui va chercher à sortir :-(
On 02 Feb 2004 20:45:28 GMT, "Jean Gab1" <"."@> wrote:
sous unix, tu fais juste un petit script shell qui appelle java avec ton jar, cela te permettras de ne pas controler javaw.exe.
(sous windows, cela doit être pareille, un fichier .bat)
Non, sous Windows ça ne marche pas : il n'y a pas de notion de processus père/fils -- cmd.exe va lire le .bat, et lancer javaw.exe qui va alors être totalement indépendant, même s'il est possible que cmd.exe attende qu'il ait fini pour continuer à lire le .bat. Du coup c'est bien javaw.exe qui va chercher à sortir :-(
-- ;-)
Jean Gab1
| Non, sous Windows ça ne marche pas : il n'y a pas de notion de | processus père/fils -- cmd.exe va lire le .bat, et lancer javaw.exe | qui va alors être totalement indépendant, même s'il est possible que | cmd.exe attende qu'il ait fini pour continuer à lire le .bat. | Du coup c'est bien javaw.exe qui va chercher à sortir :-(
ha oui, windows :)
sinon tu peux toujours essayer de compiler ton prog java en un véritable exécutable windows (cherche une version d'évaluation sur le net pour tester :) la taille de l'exécutable est très important et c'est pas très portable ... alors que java se doit d'être portable ...
bon c'est lourd comme procédure et en plus ton firewal va suremetn gueulé plein tubes car l'exe n'a plus le même md5 ou sum de base ;-)
pour une utilisation perso t'es limite parano (un peu quand même ? ;-)
-- "Je n'ai rien contre les gens qui brûlent des voitures à condition qu'ils brûlent les leurs"
| Non, sous Windows ça ne marche pas : il n'y a pas de notion de
| processus père/fils -- cmd.exe va lire le .bat, et lancer javaw.exe
| qui va alors être totalement indépendant, même s'il est possible que
| cmd.exe attende qu'il ait fini pour continuer à lire le .bat.
| Du coup c'est bien javaw.exe qui va chercher à sortir :-(
ha oui, windows :)
sinon tu peux toujours essayer de compiler ton prog java en un véritable
exécutable windows (cherche une version d'évaluation sur le net pour tester
:) la taille de l'exécutable est très important et c'est pas très portable
... alors que java se doit d'être portable ...
bon c'est lourd comme procédure et en plus ton firewal va suremetn gueulé
plein tubes car l'exe n'a plus le même md5 ou sum de base ;-)
pour une utilisation perso t'es limite parano (un peu quand même ? ;-)
--
"Je n'ai rien contre les gens qui brûlent des voitures à condition qu'ils
brûlent les leurs"
| Non, sous Windows ça ne marche pas : il n'y a pas de notion de | processus père/fils -- cmd.exe va lire le .bat, et lancer javaw.exe | qui va alors être totalement indépendant, même s'il est possible que | cmd.exe attende qu'il ait fini pour continuer à lire le .bat. | Du coup c'est bien javaw.exe qui va chercher à sortir :-(
ha oui, windows :)
sinon tu peux toujours essayer de compiler ton prog java en un véritable exécutable windows (cherche une version d'évaluation sur le net pour tester :) la taille de l'exécutable est très important et c'est pas très portable ... alors que java se doit d'être portable ...
bon c'est lourd comme procédure et en plus ton firewal va suremetn gueulé plein tubes car l'exe n'a plus le même md5 ou sum de base ;-)
pour une utilisation perso t'es limite parano (un peu quand même ? ;-)
-- "Je n'ai rien contre les gens qui brûlent des voitures à condition qu'ils brûlent les leurs"
Fabien LE LEZ
On 04 Feb 2004 13:55:20 GMT, "Jean Gab1" <"."@> wrote:
pour une utilisation perso t'es limite parano (un peu quand même ? ;-)
A priori, le gros avantage du "firewall personnel" sur un firewall "normal" (i.e. sur une autre machine, qui sert éventuellement de routeur), c'est qu'il bloque les tentatives de communication des éventuels troyens. Si maintenant n'importe quel troyen peut sortir sans que mon firewall y trouve à redire, à partir du moment où ledit troyen est écrit en Java, ça ne me paraît pas spécialement anodin, et ça réduit de façon significative l'avantage du firewall perso...
-- ;-)
On 04 Feb 2004 13:55:20 GMT, "Jean Gab1" <"."@> wrote:
pour une utilisation perso t'es limite parano (un peu quand même ? ;-)
A priori, le gros avantage du "firewall personnel" sur un firewall
"normal" (i.e. sur une autre machine, qui sert éventuellement de
routeur), c'est qu'il bloque les tentatives de communication des
éventuels troyens.
Si maintenant n'importe quel troyen peut sortir sans que mon firewall
y trouve à redire, à partir du moment où ledit troyen est écrit en
Java, ça ne me paraît pas spécialement anodin, et ça réduit de façon
significative l'avantage du firewall perso...
On 04 Feb 2004 13:55:20 GMT, "Jean Gab1" <"."@> wrote:
pour une utilisation perso t'es limite parano (un peu quand même ? ;-)
A priori, le gros avantage du "firewall personnel" sur un firewall "normal" (i.e. sur une autre machine, qui sert éventuellement de routeur), c'est qu'il bloque les tentatives de communication des éventuels troyens. Si maintenant n'importe quel troyen peut sortir sans que mon firewall y trouve à redire, à partir du moment où ledit troyen est écrit en Java, ça ne me paraît pas spécialement anodin, et ça réduit de façon significative l'avantage du firewall perso...
-- ;-)
Fabien LE LEZ
On 04 Feb 2004 13:55:20 GMT, "Jean Gab1" <"."@> wrote:
sinon tu peux toujours essayer de compiler ton prog java en un véritable exécutable windows (cherche une version d'évaluation sur le net pour tester :) la taille de l'exécutable est très important
Bof... L'application en question fait déjà plus de 15 Mo, si on compte le runtime Java que j'ai dû télécharger pour la faire fonctionner, donc ça ne risque pas d'être pire...
Sinon, il doit y avoir une autre solution : transformer javaw.exe en .dll, et créer un .exe qui appelle cette DLL après avoir bien vérifié que le .jar passé en paramètre est celui dont j'ai besoin.
Je vais finir par chercher un logiciel équivalent mais compilé, et virer tout le bazar Java, ça risque d'être plus simple ;-
et c'est pas très portable ... alors que java se doit d'être portable ...
Mouais... Le principe, c'est que c'est à l'utilisateur de se coltiner les problèmes de portabilité, alors que dans d'autres langages, c'est le programmeur qui fait le boulot. C'est "un peu" HS ici, mais je veux bien discuter de ça avec toi par email.
bon c'est lourd comme procédure et en plus ton firewal va suremetn gueulé plein tubes car l'exe n'a plus le même md5 ou sum de base ;-)
Mais une seule fois -- une fois que je l'aurai calmé (et supprimé les règles concernant javaw.exe).
-- ;-)
On 04 Feb 2004 13:55:20 GMT, "Jean Gab1" <"."@> wrote:
sinon tu peux toujours essayer de compiler ton prog java en un véritable
exécutable windows (cherche une version d'évaluation sur le net pour tester
:) la taille de l'exécutable est très important
Bof... L'application en question fait déjà plus de 15 Mo, si on compte
le runtime Java que j'ai dû télécharger pour la faire fonctionner,
donc ça ne risque pas d'être pire...
Sinon, il doit y avoir une autre solution : transformer javaw.exe en
.dll, et créer un .exe qui appelle cette DLL après avoir bien vérifié
que le .jar passé en paramètre est celui dont j'ai besoin.
Je vais finir par chercher un logiciel équivalent mais compilé, et
virer tout le bazar Java, ça risque d'être plus simple ;-
et c'est pas très portable
... alors que java se doit d'être portable ...
Mouais... Le principe, c'est que c'est à l'utilisateur de se coltiner
les problèmes de portabilité, alors que dans d'autres langages, c'est
le programmeur qui fait le boulot. C'est "un peu" HS ici, mais je veux
bien discuter de ça avec toi par email.
bon c'est lourd comme procédure et en plus ton firewal va suremetn gueulé
plein tubes car l'exe n'a plus le même md5 ou sum de base ;-)
Mais une seule fois -- une fois que je l'aurai calmé (et supprimé les
règles concernant javaw.exe).
On 04 Feb 2004 13:55:20 GMT, "Jean Gab1" <"."@> wrote:
sinon tu peux toujours essayer de compiler ton prog java en un véritable exécutable windows (cherche une version d'évaluation sur le net pour tester :) la taille de l'exécutable est très important
Bof... L'application en question fait déjà plus de 15 Mo, si on compte le runtime Java que j'ai dû télécharger pour la faire fonctionner, donc ça ne risque pas d'être pire...
Sinon, il doit y avoir une autre solution : transformer javaw.exe en .dll, et créer un .exe qui appelle cette DLL après avoir bien vérifié que le .jar passé en paramètre est celui dont j'ai besoin.
Je vais finir par chercher un logiciel équivalent mais compilé, et virer tout le bazar Java, ça risque d'être plus simple ;-
et c'est pas très portable ... alors que java se doit d'être portable ...
Mouais... Le principe, c'est que c'est à l'utilisateur de se coltiner les problèmes de portabilité, alors que dans d'autres langages, c'est le programmeur qui fait le boulot. C'est "un peu" HS ici, mais je veux bien discuter de ça avec toi par email.
bon c'est lourd comme procédure et en plus ton firewal va suremetn gueulé plein tubes car l'exe n'a plus le même md5 ou sum de base ;-)
Mais une seule fois -- une fois que je l'aurai calmé (et supprimé les règles concernant javaw.exe).
-- ;-)
Emmanuel Florac
Dans article , disait...
Ça me paraît une faille de sécurité : n'importe quel troyen écrit en Java va donc pouvoir expédier ses données comme bon lui semble.
Oui.
Qu'en pensez-vous ? Y a-t-il un moyen de contourner le problème ?
Aucun. D'ailleurs le même problème se pose quand tu as plusieurs applications java qui tournent et qu'une se plante : dans la liste des processus tu n'as que des "javaw", alors va savoir lequel flinguer...
Mon avis à moi que j'ai : java c'est peut-être à la mode, mais globalement c'est de la crotte.
Bon, tu as un dernier petit espoir : il est parfois possible de compiler un prograémme java en un éxecutable natif. Bien sûr ça implique d'avoir le kit de dev ad hoc (genre Borland Jbuilder) ET les sources de l'application.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <ddro10dg2tr3fitlohpq3a375kh206frq1@4ax.com>,
gramster@gramster.com disait...
Ça me paraît une faille de sécurité : n'importe quel troyen écrit en
Java va donc pouvoir expédier ses données comme bon lui semble.
Oui.
Qu'en pensez-vous ? Y a-t-il un moyen de contourner le problème ?
Aucun. D'ailleurs le même problème se pose quand tu as plusieurs
applications java qui tournent et qu'une se plante : dans la liste des
processus tu n'as que des "javaw", alors va savoir lequel flinguer...
Mon avis à moi que j'ai : java c'est peut-être à la mode, mais
globalement c'est de la crotte.
Bon, tu as un dernier petit espoir : il est parfois possible de compiler
un prograémme java en un éxecutable natif. Bien sûr ça implique d'avoir
le kit de dev ad hoc (genre Borland Jbuilder) ET les sources de
l'application.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Ça me paraît une faille de sécurité : n'importe quel troyen écrit en Java va donc pouvoir expédier ses données comme bon lui semble.
Oui.
Qu'en pensez-vous ? Y a-t-il un moyen de contourner le problème ?
Aucun. D'ailleurs le même problème se pose quand tu as plusieurs applications java qui tournent et qu'une se plante : dans la liste des processus tu n'as que des "javaw", alors va savoir lequel flinguer...
Mon avis à moi que j'ai : java c'est peut-être à la mode, mais globalement c'est de la crotte.
Bon, tu as un dernier petit espoir : il est parfois possible de compiler un prograémme java en un éxecutable natif. Bien sûr ça implique d'avoir le kit de dev ad hoc (genre Borland Jbuilder) ET les sources de l'application.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Fabien LE LEZ
On 07 Feb 2004 11:17:40 GMT, Emmanuel Florac wrote:
Aucun. D'ailleurs le même problème se pose quand tu as plusieurs applications java qui tournent et qu'une se plante : dans la liste des processus tu n'as que des "javaw", alors va savoir lequel flinguer...
Pour ce genre de problèmes, j'essaie de me rappeler l'ordre de lancement, et je me sers du PID.
Mon avis à moi que j'ai : java c'est peut-être à la mode, mais globalement c'est de la crotte.
_C'était_ à la mode. Pour le web, Flash l'a très largement supplanté, et hors du web (applications "normales"), ça n'a jamais eu grand succès (ni grand intérêt d'ailleurs). C'est d'ailleurs peut-être ce qui me sauvera : je suppose qu'aucun pirate n'ira imaginer créer un troyen en Java -- le déploiement serait trop compliqué (c'est déjà assez difficile quand le propriétaire de la machine est d'accord...)
-- ;-)
On 07 Feb 2004 11:17:40 GMT, Emmanuel Florac <eflorac@verisign.com>
wrote:
Aucun. D'ailleurs le même problème se pose quand tu as plusieurs
applications java qui tournent et qu'une se plante : dans la liste des
processus tu n'as que des "javaw", alors va savoir lequel flinguer...
Pour ce genre de problèmes, j'essaie de me rappeler l'ordre de
lancement, et je me sers du PID.
Mon avis à moi que j'ai : java c'est peut-être à la mode, mais
globalement c'est de la crotte.
_C'était_ à la mode. Pour le web, Flash l'a très largement supplanté,
et hors du web (applications "normales"), ça n'a jamais eu grand
succès (ni grand intérêt d'ailleurs).
C'est d'ailleurs peut-être ce qui me sauvera : je suppose qu'aucun
pirate n'ira imaginer créer un troyen en Java -- le déploiement serait
trop compliqué (c'est déjà assez difficile quand le propriétaire de la
machine est d'accord...)
On 07 Feb 2004 11:17:40 GMT, Emmanuel Florac wrote:
Aucun. D'ailleurs le même problème se pose quand tu as plusieurs applications java qui tournent et qu'une se plante : dans la liste des processus tu n'as que des "javaw", alors va savoir lequel flinguer...
Pour ce genre de problèmes, j'essaie de me rappeler l'ordre de lancement, et je me sers du PID.
Mon avis à moi que j'ai : java c'est peut-être à la mode, mais globalement c'est de la crotte.
_C'était_ à la mode. Pour le web, Flash l'a très largement supplanté, et hors du web (applications "normales"), ça n'a jamais eu grand succès (ni grand intérêt d'ailleurs). C'est d'ailleurs peut-être ce qui me sauvera : je suppose qu'aucun pirate n'ira imaginer créer un troyen en Java -- le déploiement serait trop compliqué (c'est déjà assez difficile quand le propriétaire de la machine est d'accord...)
