Bonjour,
J'ai entendu plusieurs fois des gens évoquer un problème de sécurité
connu sous le nom de fenêtre de vulnérabilité.
Je ne suis pas sûr de savoir expliquer correctement le problème, mais il
s'agit plus ou moins d'accéder à un code normalement sécurisé par un
thread concurrent qui se déclencherait pendant une fenêtre de
vulnérabilité ouverte par le thread exécutant le mécanisme de protection.
Je souhaiterai seulement savoir s'il s'agit d'un problème théorique ou
d'un problème que l'on peut vraiment rencontré? Dans mon esprit, il me
semble qu'il faudrait être capable de forcer les exécutions dans un
ordre bien particulier, et ceci repose sur trop de paramètres pour
vraiment être contrôlé.
Mei
J'ai l'impression qu'on est mal partie pour ce comprendre ;-)
Et pourtant je fais des efforts ;) Bon allez, plus sérieusement, ok, je ne me suis pas exprimé suffisamment clairement. La raison en est que j'ai commencé à poser ma question initiale sur la base de souvenirs plus ou moins vagues de discussions passées. Recommençons avec le recul que j'ai pu obtenir en la posant ci et là.
Je vais récapituler certaines choses : - Une faille de sécurité théorique, c'est un type bug dans une application qui peut être utilisé pour outrepasser les droits qu'on devrait avoir.
Ok, et donc une faille de sécurité pratique?
- Le JDK en général et le SecurityManager ont maintenant plus d'une 10zaine d'année d'existance, et aucun bug (de ce type) n'y a été trouvé. Je pense qu'on peut les considérer comme relativement sûr.
Ca je ne le remet pas en cause.
- Si bug il y a dans une application, alors elle devient vulnérable. La simplicité ou la difficulté d'exploitation dépends fortement du contexte.
Ok.
Ensuite, quand je te demande si tu cherche à exploiter une faille ou à t'en protéger, c'est une vrai question.
Et c'est une vraie réponse quand je dis que je ne suis dans aucun contexte: je cherche juste à comprendre pourquoi certaines personnes évoquent de temps en temps ce problème, ce qu'il y a vraiment derrière ça.
[...]
Donc si ta question est de savoir si un code buggé peut-être vulnérable à une attaque par fenêtre de vulnérabilité, la réponse est clairement oui.
Ma question est bien là. Je voulais comprendre à quelles subtilités du langage et/ou de l'environnement il faut prendre garde pour éviter ce genre d'attaques, ainsi que les façons de les opérer, en prenant des classes "victimes" qui ne seraient pas ad hoc du genre: public attaqueMoi(MutableType foreignParameter) { if (isSafe(foreignParameter)) { Thread.sleep(5000); // changez-moi à volonté maintenant que j'ai fait mon test défensif this.foreignParameter = foreignParameter.clone(); doSensibleJobThatRelyOnInvariantsOf(foreignParameter); } else throw new IllegalArgumentException("On ne me la fait pas à moi!!"); } Bien sûr, vous pourriez me répondre qu'il suffira de faire la copie du paramètre et ensuite d'effectuer le test défensif (pour supprimer la fenêtre de vulnérabilité), mais ca ne répondrait qu'en partie à la question. L'autre partie serait comment on attaque si la fenêtre existe sans que l'on soit en présence de ce gros Thread.sleep() (en effet, je pense mis à part ce Thread.sleep(), l'idiome "je teste les paramètres et s'ils sont valides je les copie" est assez fréquent). Donc ma question aurait sans doute mieux été acceptée, si je l'avais formulée ainsi dès le départ : de quels moyens dispose-t-on pour maximiser nos chances que le thread attaquant se déclenche au bon moment? Ainsi, pour le moment, les débuts de réponses que j'ai sont: - l'utilisation d'un debuggeur quand c'est possible - la surcharge des méthodes equals() et/ou hashCode() si on passe un paramètre que l'objet met dans une table de hachage - la pose de verrous sur des enregistrements si l'objet fait des appels en base Si vous avez d'autres idées, elles sont les bienvenues ;) (et encore une fois, non, je ne cherche pas à rafler un prix pour l'attaque d'un vrai code: le seul qui est à ma disposition aujourd'hui est le pseudo code que je viens d'écrire ci-dessus)
Si la question est de savoir si la présence de ce type de bug est lié à l'implémentation de Java, la réponse est non, au moins jusqu'à ce que toi ou quelqu'un d'autre en apporte la preuve.
Non, ce n'est pas ce qui m'intéresse ici. Mei
J'ai l'impression qu'on est mal partie pour ce comprendre ;-)
Et pourtant je fais des efforts ;)
Bon allez, plus sérieusement, ok, je ne me suis pas exprimé suffisamment
clairement. La raison en est que j'ai commencé à poser ma question
initiale sur la base de souvenirs plus ou moins vagues de discussions
passées.
Recommençons avec le recul que j'ai pu obtenir en la posant ci et là.
Je vais récapituler certaines choses :
- Une faille de sécurité théorique, c'est un type bug dans une
application qui peut être utilisé pour outrepasser les droits qu'on
devrait avoir.
Ok, et donc une faille de sécurité pratique?
- Le JDK en général et le SecurityManager ont maintenant plus d'une
10zaine d'année d'existance, et aucun bug (de ce type) n'y a été trouvé.
Je pense qu'on peut les considérer comme relativement sûr.
Ca je ne le remet pas en cause.
- Si bug il y a dans une application, alors elle devient vulnérable.
La simplicité ou la difficulté d'exploitation dépends fortement du
contexte.
Ok.
Ensuite, quand je te demande si tu cherche à exploiter une faille ou à
t'en protéger, c'est une vrai question.
Et c'est une vraie réponse quand je dis que je ne suis dans aucun
contexte: je cherche juste à comprendre pourquoi certaines personnes
évoquent de temps en temps ce problème, ce qu'il y a vraiment derrière ça.
[...]
Donc si ta question est de savoir si un code buggé peut-être vulnérable
à une attaque par fenêtre de vulnérabilité, la réponse est clairement
oui.
Ma question est bien là. Je voulais comprendre à quelles subtilités du
langage et/ou de l'environnement il faut prendre garde pour éviter ce
genre d'attaques, ainsi que les façons de les opérer, en prenant des
classes "victimes" qui ne seraient pas ad hoc du genre:
public attaqueMoi(MutableType foreignParameter) {
if (isSafe(foreignParameter)) {
Thread.sleep(5000); // changez-moi à volonté maintenant que j'ai
fait mon test défensif
this.foreignParameter = foreignParameter.clone();
doSensibleJobThatRelyOnInvariantsOf(foreignParameter);
} else
throw new IllegalArgumentException("On ne me la fait pas à moi!!");
}
Bien sûr, vous pourriez me répondre qu'il suffira de faire la copie du
paramètre et ensuite d'effectuer le test défensif (pour supprimer la
fenêtre de vulnérabilité), mais ca ne répondrait qu'en partie à la
question. L'autre partie serait comment on attaque si la fenêtre existe
sans que l'on soit en présence de ce gros Thread.sleep() (en effet, je
pense mis à part ce Thread.sleep(), l'idiome "je teste les paramètres et
s'ils sont valides je les copie" est assez fréquent).
Donc ma question aurait sans doute mieux été acceptée, si je l'avais
formulée ainsi dès le départ : de quels moyens dispose-t-on pour
maximiser nos chances que le thread attaquant se déclenche au bon moment?
Ainsi, pour le moment, les débuts de réponses que j'ai sont:
- l'utilisation d'un debuggeur quand c'est possible
- la surcharge des méthodes equals() et/ou hashCode() si on passe un
paramètre que l'objet met dans une table de hachage
- la pose de verrous sur des enregistrements si l'objet fait des appels
en base
Si vous avez d'autres idées, elles sont les bienvenues ;) (et encore une
fois, non, je ne cherche pas à rafler un prix pour l'attaque d'un vrai
code: le seul qui est à ma disposition aujourd'hui est le pseudo code
que je viens d'écrire ci-dessus)
Si la question est de savoir si la présence de ce type de bug est
lié à l'implémentation de Java, la réponse est non, au moins jusqu'à ce
que toi ou quelqu'un d'autre en apporte la preuve.
J'ai l'impression qu'on est mal partie pour ce comprendre ;-)
Et pourtant je fais des efforts ;) Bon allez, plus sérieusement, ok, je ne me suis pas exprimé suffisamment clairement. La raison en est que j'ai commencé à poser ma question initiale sur la base de souvenirs plus ou moins vagues de discussions passées. Recommençons avec le recul que j'ai pu obtenir en la posant ci et là.
Je vais récapituler certaines choses : - Une faille de sécurité théorique, c'est un type bug dans une application qui peut être utilisé pour outrepasser les droits qu'on devrait avoir.
Ok, et donc une faille de sécurité pratique?
- Le JDK en général et le SecurityManager ont maintenant plus d'une 10zaine d'année d'existance, et aucun bug (de ce type) n'y a été trouvé. Je pense qu'on peut les considérer comme relativement sûr.
Ca je ne le remet pas en cause.
- Si bug il y a dans une application, alors elle devient vulnérable. La simplicité ou la difficulté d'exploitation dépends fortement du contexte.
Ok.
Ensuite, quand je te demande si tu cherche à exploiter une faille ou à t'en protéger, c'est une vrai question.
Et c'est une vraie réponse quand je dis que je ne suis dans aucun contexte: je cherche juste à comprendre pourquoi certaines personnes évoquent de temps en temps ce problème, ce qu'il y a vraiment derrière ça.
[...]
Donc si ta question est de savoir si un code buggé peut-être vulnérable à une attaque par fenêtre de vulnérabilité, la réponse est clairement oui.
Ma question est bien là. Je voulais comprendre à quelles subtilités du langage et/ou de l'environnement il faut prendre garde pour éviter ce genre d'attaques, ainsi que les façons de les opérer, en prenant des classes "victimes" qui ne seraient pas ad hoc du genre: public attaqueMoi(MutableType foreignParameter) { if (isSafe(foreignParameter)) { Thread.sleep(5000); // changez-moi à volonté maintenant que j'ai fait mon test défensif this.foreignParameter = foreignParameter.clone(); doSensibleJobThatRelyOnInvariantsOf(foreignParameter); } else throw new IllegalArgumentException("On ne me la fait pas à moi!!"); } Bien sûr, vous pourriez me répondre qu'il suffira de faire la copie du paramètre et ensuite d'effectuer le test défensif (pour supprimer la fenêtre de vulnérabilité), mais ca ne répondrait qu'en partie à la question. L'autre partie serait comment on attaque si la fenêtre existe sans que l'on soit en présence de ce gros Thread.sleep() (en effet, je pense mis à part ce Thread.sleep(), l'idiome "je teste les paramètres et s'ils sont valides je les copie" est assez fréquent). Donc ma question aurait sans doute mieux été acceptée, si je l'avais formulée ainsi dès le départ : de quels moyens dispose-t-on pour maximiser nos chances que le thread attaquant se déclenche au bon moment? Ainsi, pour le moment, les débuts de réponses que j'ai sont: - l'utilisation d'un debuggeur quand c'est possible - la surcharge des méthodes equals() et/ou hashCode() si on passe un paramètre que l'objet met dans une table de hachage - la pose de verrous sur des enregistrements si l'objet fait des appels en base Si vous avez d'autres idées, elles sont les bienvenues ;) (et encore une fois, non, je ne cherche pas à rafler un prix pour l'attaque d'un vrai code: le seul qui est à ma disposition aujourd'hui est le pseudo code que je viens d'écrire ci-dessus)
Si la question est de savoir si la présence de ce type de bug est lié à l'implémentation de Java, la réponse est non, au moins jusqu'à ce que toi ou quelqu'un d'autre en apporte la preuve.
Non, ce n'est pas ce qui m'intéresse ici. Mei
fabrice.pas-de-spam.bacchella
On Wed, 28 Feb 2007 10:14:54 +0100, TestMan wrote:
Enfin, la sortie sous GPL approchant, celà va permettre au plus grand nombre de se plonger dans le code natif et pousser l'analyse de la sécurité plus en avant (le code est déjà disponible actuellement, mais de mémoire certaines restrictions peuvent limiter les travaux d'analyse d'ataque ... ).
Combien de fois faudra-t-il le dire ? Le code de la JVM de référence (celle de Sun) est déjà disponible depuis bien longtemps. C'est juste la licence qui change !
On Wed, 28 Feb 2007 10:14:54 +0100, TestMan <none@example.com> wrote:
Enfin, la sortie sous GPL approchant, celà va permettre au plus grand
nombre de se plonger dans le code natif et pousser l'analyse de la
sécurité plus en avant (le code est déjà disponible actuellement, mais
de mémoire certaines restrictions peuvent limiter les travaux d'analyse
d'ataque ... ).
Combien de fois faudra-t-il le dire ? Le code de la JVM de référence
(celle de Sun) est déjà disponible depuis bien longtemps. C'est juste
la licence qui change !
On Wed, 28 Feb 2007 10:14:54 +0100, TestMan wrote:
Enfin, la sortie sous GPL approchant, celà va permettre au plus grand nombre de se plonger dans le code natif et pousser l'analyse de la sécurité plus en avant (le code est déjà disponible actuellement, mais de mémoire certaines restrictions peuvent limiter les travaux d'analyse d'ataque ... ).
Combien de fois faudra-t-il le dire ? Le code de la JVM de référence (celle de Sun) est déjà disponible depuis bien longtemps. C'est juste la licence qui change !
TestMan
On Wed, 28 Feb 2007 10:14:54 +0100, TestMan wrote:
Enfin, la sortie sous GPL approchant, celà va permettre au plus grand nombre de se plonger dans le code natif et pousser l'analyse de la sécurité plus en avant (le code est déjà disponible actuellement, mais de mémoire certaines restrictions peuvent limiter les travaux d'analyse d'ataque ... ).
Combien de fois faudra-t-il le dire ? Le code de la JVM de référence (celle de Sun) est déjà disponible depuis bien longtemps. C'est juste la licence qui change !
En premier, non ce n'est pas le seul changement, tout le code source n'est pas disponible actuelement. Certains fichiers sont en binaire (binaires créés par des tiers). Ce point semble avoir particulierement freiner la publication du code source si l'on en croit Sun. Ainsi, afin de livrer des sources complètes du JDK, il leur faut trouver des équivalents libre ou bouchoner le cas échéant.
Quand à la JRL (ou encore la SCSL), elle impose des restrictions d'utilisations en environement comerciaux problèmatiques. Par exemple, vous êtes sur un projet pour un client (genre forfait) et vous avez en face de vous un problème bloquant avec la VM, actuellement la seule solution est de contourner avec des vilaines rustines. Et espérer que on "dérustinera" le jour ou c'est corrigé (en croisant les doigts, que le jour ou l'oublit de la rustine ne provoque pas une régression). Maintenant, vous aller pouvoir concevoir directement un patch, et pourquoi pas le pousser directement dans l'arbre de référence aprés validation...
Ceux qui ont ténté de faire passer des patches dans le JDK comprendront la différence fondamentale que celà représente.
A+ TM
On Wed, 28 Feb 2007 10:14:54 +0100, TestMan <none@example.com> wrote:
Enfin, la sortie sous GPL approchant, celà va permettre au plus grand
nombre de se plonger dans le code natif et pousser l'analyse de la
sécurité plus en avant (le code est déjà disponible actuellement, mais
de mémoire certaines restrictions peuvent limiter les travaux d'analyse
d'ataque ... ).
Combien de fois faudra-t-il le dire ? Le code de la JVM de référence
(celle de Sun) est déjà disponible depuis bien longtemps. C'est juste
la licence qui change !
En premier, non ce n'est pas le seul changement, tout le code source
n'est pas disponible actuelement. Certains fichiers sont en binaire
(binaires créés par des tiers). Ce point semble avoir particulierement
freiner la publication du code source si l'on en croit Sun. Ainsi, afin
de livrer des sources complètes du JDK, il leur faut trouver des
équivalents libre ou bouchoner le cas échéant.
Quand à la JRL (ou encore la SCSL), elle impose des restrictions
d'utilisations en environement comerciaux problèmatiques. Par exemple,
vous êtes sur un projet pour un client (genre forfait) et vous avez en
face de vous un problème bloquant avec la VM, actuellement la seule
solution est de contourner avec des vilaines rustines. Et espérer que on
"dérustinera" le jour ou c'est corrigé (en croisant les doigts, que le
jour ou l'oublit de la rustine ne provoque pas une régression).
Maintenant, vous aller pouvoir concevoir directement un patch, et
pourquoi pas le pousser directement dans l'arbre de référence aprés
validation...
Ceux qui ont ténté de faire passer des patches dans le JDK comprendront
la différence fondamentale que celà représente.
On Wed, 28 Feb 2007 10:14:54 +0100, TestMan wrote:
Enfin, la sortie sous GPL approchant, celà va permettre au plus grand nombre de se plonger dans le code natif et pousser l'analyse de la sécurité plus en avant (le code est déjà disponible actuellement, mais de mémoire certaines restrictions peuvent limiter les travaux d'analyse d'ataque ... ).
Combien de fois faudra-t-il le dire ? Le code de la JVM de référence (celle de Sun) est déjà disponible depuis bien longtemps. C'est juste la licence qui change !
En premier, non ce n'est pas le seul changement, tout le code source n'est pas disponible actuelement. Certains fichiers sont en binaire (binaires créés par des tiers). Ce point semble avoir particulierement freiner la publication du code source si l'on en croit Sun. Ainsi, afin de livrer des sources complètes du JDK, il leur faut trouver des équivalents libre ou bouchoner le cas échéant.
Quand à la JRL (ou encore la SCSL), elle impose des restrictions d'utilisations en environement comerciaux problèmatiques. Par exemple, vous êtes sur un projet pour un client (genre forfait) et vous avez en face de vous un problème bloquant avec la VM, actuellement la seule solution est de contourner avec des vilaines rustines. Et espérer que on "dérustinera" le jour ou c'est corrigé (en croisant les doigts, que le jour ou l'oublit de la rustine ne provoque pas une régression). Maintenant, vous aller pouvoir concevoir directement un patch, et pourquoi pas le pousser directement dans l'arbre de référence aprés validation...
Ceux qui ont ténté de faire passer des patches dans le JDK comprendront la différence fondamentale que celà représente.
