[securite] fenêtre de vulnerabilité

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

Bonjour,

A ma connaissance, Java n'est pas sensible à ce genre de chose pour une
simple question de prédictabilité.

En effet, non seulement l'odonancement des thread en Java est peu
prévisible (comportement du JIT de la machine cible + ordonancement des
thread du système hote). Mais en plus, le modèle de mémoire de Java ne
permet pas au travers de code (sauf bug eventuel de la VM) d'accéder à
un espace de mémoire en direct hors de tout controle (au contraire du
code .net "non géré" par exemple). En clair, sauf à avoir une faille
dans le SecurityManager pour accéder à des API natives permetant ce
genre de controle, rien en perspective.

Bien sûr, il y a la théorie et la pratique, sauf que dans le cas présent
si l'on liste l'ensemble des failles découvertes dans le JIT ou la VM
(partie native) depuis 10ans, on peut largement considérer que la
plateforme est largement sécurisée et surtout que les failles
découvertes sont des erreurs et ne remettent pas en cause le modèle de
sécurité initial. Pour bien préciser le point, vu la Visibilité qu'à
Java depuis 10 ans, vous pouvez imaginer que pas mal de pro du domaine
on fait des tentatives pour trouver "le point faible", mais rien jusqu'à
ce jour ...

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 ... ).

A+
TM

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

Bonjour,

A ma connaissance, Java n'est pas sensible à ce genre de chose pour une
simple question de prédictabilité.

En effet, non seulement l'odonancement des thread en Java est peu
prévisible (comportement du JIT de la machine cible + ordonancement des
thread du système hote). Mais en plus, le modèle de mémoire de Java ne
permet pas au travers de code (sauf bug eventuel de la VM) d'accéder à
un espace de mémoire en direct hors de tout controle (au contraire du
code .net "non géré" par exemple). En clair, sauf à avoir une faille
dans le SecurityManager pour accéder à des API natives permetant ce
genre de controle, rien en perspective.

Je ne pense pas qu'un bug de la JVM soit nécessaire. De ce que je me
souviens de la dernière fois que j'ai entendu parlé de ce problème,
l'attaque se passerait ainsi:
On passe en argument une chaîne de caractère mutable (donc pas un
String, et c'est donc là que la faille de sécurité est faîte) à une
méthode de la classe attaquée. La méthode effectue des contrôles de
sécurité et on a pris soin que la chaîne soit valide à ce moment.
Ensuite l'attaque consisterait à modifier la chaîne par un autre thread
tandis que les contrôles ont été effectués alors que la méthode est
toujours en cours d'exécution! (la fameuse fenêtre de vulnérabilité).
Après y avoir re-réfléchi, ce qui me gênait là-dedans, c'est comme tu
l'as noté, le problème de prédictabilité: on ne pourra garantir
l'exécution du thread d'attaque au bon moment, et ma question était donc
est-ce un risque théorique ou pas?

Mei

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

Bonjour,

A ma connaissance, Java n'est pas sensible à ce genre de chose pour
une simple question de prédictabilité.

En effet, non seulement l'odonancement des thread en Java est peu
prévisible (comportement du JIT de la machine cible + ordonancement
des thread du système hote). Mais en plus, le modèle de mémoire de
Java ne permet pas au travers de code (sauf bug eventuel de la VM)
d'accéder à un espace de mémoire en direct hors de tout controle (au
contraire du code .net "non géré" par exemple). En clair, sauf à avoir
une faille dans le SecurityManager pour accéder à des API natives
permetant ce genre de controle, rien en perspective.

Je ne pense pas qu'un bug de la JVM soit nécessaire. De ce que je me
souviens de la dernière fois que j'ai entendu parlé de ce problème,
l'attaque se passerait ainsi:
On passe en argument une chaîne de caractère mutable (donc pas un
String, et c'est donc là que la faille de sécurité est faîte) à une
méthode de la classe attaquée. La méthode effectue des contrôles de
sécurité et on a pris soin que la chaîne soit valide à ce moment.
Ensuite l'attaque consisterait à modifier la chaîne par un autre thread
tandis que les contrôles ont été effectués alors que la méthode est
toujours en cours d'exécution! (la fameuse fenêtre de vulnérabilité).
Après y avoir re-réfléchi, ce qui me gênait là-dedans, c'est comme tu
l'as noté, le problème de prédictabilité: on ne pourra garantir
l'exécution du thread d'attaque au bon moment, et ma question était donc
est-ce un risque théorique ou pas?

Mei

Bonjour Mei,

Je n'ai pas d'API en tête dans Java qui prennent un StringBuilder ni
StringBuffer, mais il doit bien y en avoir ;-)
(seul quelques char[] sur les mots de passe pour éviter leur
internalisation dans les constantes)

Quand à ce dont vous parlez, si votre code dispose de le bonne "clé" à
un instant T, vous en disposez pour toute votre Application y comprit à
T+N (N>0), je vois pas en quoi ce serait un exploit de le passer à un
autre fil. J'ai raté qqch ?

Celà ne signifie pas qu'il n'y a pas de PB, simplement que l'on reste
sur les problèmatiques classiques du multithread qui sont elles bien
réelles.

Dans ce cas, personellement, si j'ai un doute sur la persistence de
l'information dans le cycle, je garde unce référence sur la valeur,
l'objet immutable ou je clone.

Pour le reste, c'est du thèorique, et j'attend de voir une maquette
d'une attaque du type que tu décris ;-)

A+
TM

Bonjour Mei,

Bonsoir TestMan

Je n'ai pas d'API en tête dans Java qui prennent un StringBuilder ni
StringBuffer, mais il doit bien y en avoir ;-)
(seul quelques char[] sur les mots de passe pour éviter leur
internalisation dans les constantes)

Notons, que le paramètre passé n'a pas besoin d'être de type chaine de
caractère: l'attaque pourrait être possible chaque fois qu'on passe un
objet mutable ou un objet d'un type non final.

Quand à ce dont vous parlez, si votre code dispose de le bonne "clé" à
un instant T, vous en disposez pour toute votre Application y comprit à
T+N (N>0), je vois pas en quoi ce serait un exploit de le passer à un
autre fil. J'ai raté qqch ?

"clé" ici peut revêtir plusieurs significations. S'il s'agit d'un mot de
passe, bien sûr, aucun intérêt.
S'il s'agit de passer outre un test défensif (qui est, par exemple,
destiné à éviter un possible buffer overflow plus loin), là ça prend
tout son intérêt ;)
Dès lors que l'on est parvenu à violer les invariants d'un code, on peut
alors tout imaginer.

Celà ne signifie pas qu'il n'y a pas de PB, simplement que l'on reste
sur les problèmatiques classiques du multithread qui sont elles bien
réelles.

Oui, si ce n'est qu'en général, on cherche à éviter ces problèmatiques
classiques plutôt qu'à les exploiter :p

Dans ce cas, personellement, si j'ai un doute sur la persistence de
l'information dans le cycle, je garde unce référence sur la valeur,
l'objet immutable ou je clone.

Bien sûr la discussion n'a de sens que si l'on fait l'hypothèse que
l'objet attaqué présente un faille de sécurité.

Pour le reste, c'est du thèorique, et j'attend de voir une maquette
d'une attaque du type que tu décris ;-)

J'ai posé la question ailleurs, et même si je n'ai pas encore de quoi
faire cette maquette (il me manque la mise à disponibilité d'une classe
que je saurais être potentiellement attaquable, et ça ne me motive pas
de l'écrire moi-même :p), on m'a donné des idées intéressantes.
Le challenge est de maximiser la probabilité que notre code soit
exécuter lors de la fenêtre de vulnérabilité. L'idée est donc de trouver
un moyen de ralentir l'exécution du code attaqué (sans le bloquer) pour
laisser la fenêtre ouverte le plus longtemps possible. Les façons de
ralentir ce code doivent bien sûr s'analyser au cas par cas.

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

C'est un peu près toujours pareil quand on parle de sécurité
informatique, tout dépends des conditions et des contraintes.
Une mesure de protection ou une faille potentiel ne s'étudie que dans un
contexte. Sans contexte, c'est de la théorie, et c'est toujours
possible, une fois qu'on ajoute un contexte, c'est de la pratique et
cela dépends du contexte que l'on ajoute.

Prenons un exemple avec un mesure de protection : Est-ce qu'un digi-code
de 4 chiffres permets de sécuriser l'ouverture d'une porte ?
Théoriquement non, puisqu'il est possible de tester toutes les combinaison.
Si la porte est dans un terrain vague, rien n'empèche de tester toutes
les combinaisons, avec un peu de patience, on finira par l'ouvrir.
Si la porte permet l'accès à un batiment, et qu'un gardien la surveille,
il ne sera plus possible de tester les 1000 combinaison sans que l'on
nous pose des questions.


Revenons à ta faille de sécurité, et voyons dans quel contexte tu
pourrais chercher à l'exploiter :
Si c'est du code qui s'exécute en local sur ta machine, alors il est
très facile d'exploiter la faille (en utilisant un débuggeur pour
contrôler l'exécution de l'application).
Si tu cherche à l'exploiter en exécutant un programme sur un autre
ordinateur, mais que tu as la possibilité d'exécuter des millier de
tentative, ca risque d'être long, mais çà peut finir par passer.
Tout dépends aussi de la taille de la fenêtre, dans certain cas, elle ne
durera peut être que quelque cycle de CPU, dans d'autres, plusieurs
minutes. Les chances de réussir à l'exploiter peuvent donc etre presque
nul, ou très probable...


Alors, dans quel contexte es-tu ?
Cherche tu as protèger ton code, ou exploiter la faille dans celui d'un
autre ? ;-)


Black Myst

C'est un peu près toujours pareil quand on parle de sécurité
informatique, tout dépends des conditions et des contraintes.
Une mesure de protection ou une faille potentiel ne s'étudie que dans un
contexte. Sans contexte, c'est de la théorie, et c'est toujours
possible, une fois qu'on ajoute un contexte, c'est de la pratique et
cela dépends du contexte que l'on ajoute.

Je suis d'accord. Notons quand même que des idées peuvent déjà ne pas
passer le stade de la théorie: si, hors de tout contexte, on peut
démontrer que l'exploit n'a qu'une chance sur un milliard de succès, il
est déjà inutile de vouloir essayer de passer à la pratique.

[...]


Revenons à ta faille de sécurité, et voyons dans quel contexte tu
pourrais chercher à l'exploiter :
Si c'est du code qui s'exécute en local sur ta machine, alors il est
très facile d'exploiter la faille (en utilisant un débuggeur pour
contrôler l'exécution de l'application).

Dans certain contexte, le debugger peut être aussi utilisé en remote.

Si tu cherche à l'exploiter en exécutant un programme sur un autre
ordinateur, mais que tu as la possibilité d'exécuter des millier de
tentative, ca risque d'être long, mais çà peut finir par passer.
Tout dépends aussi de la taille de la fenêtre, dans certain cas, elle ne
durera peut être que quelque cycle de CPU, dans d'autres, plusieurs
minutes. Les chances de réussir à l'exploiter peuvent donc etre presque
nul, ou très probable...

Vrai, mais une fois encore, il est parfois possible de contrôler plus ou
moins sa durée. Ceci dépend bien sûr du code exécuté pendant la fenêtre.
Juste quelques exemples de ce qu'on pourrait faire (si l'utilisation
d'un débugger n'est pas possible):
Si le code met dans une table de hashage une clé qui lui est passé en
paramètre => Redéfinir hashCode() ou equals() pour les rendre
horriblement longues.
Si le code fait un accès en base=> poser des verrous sur les enregistrements
etc...

Alors, dans quel contexte es-tu ?

Je ne suis dans aucun contexte: comme indiqué dans mon post initial,
c'est une idée que j'ai déjà entendue plusieurs fois. Dernièrement j'ai
été piqué par la curiosité, car si auparavant, j'avais juste reçu
l'information, aujourd'hui, je voudrais d'abord comprendre si c'est
quelque chose pour lequel il vaut le coup de prêter un peu d'attention,
ou s'il s'agit seulement d'un délire de théoricien pur, au chance de
succès avoisinant les 1 chances sur 1 milliard ;)

Cherche tu as protèger ton code, ou exploiter la faille dans celui d'un
autre ? ;-)

Les grands manitous de la sécurité prêchent toujours que la sécurité est
l'affaire de tous, et lorsqu'on s'y intéresse, on se fait accuser d'être
un pirate :p

<...>

Cherche tu as protèger ton code, ou exploiter la faille dans celui
d'un autre ? ;-)

Les grands manitous de la sécurité prêchent toujours que la sécurité est
l'affaire de tous, et lorsqu'on s'y intéresse, on se fait accuser d'être
un pirate :p

Apporte la preuve (maquette complète) que ce que tu avances existe bien
dans la pratique sur la plateforme Java et qu'il a une probabilité
"importante" (tout est relatif, hein!), et on rediscutera tous ensemble
sur le sujet avec plaisir...

Pour l'instant, j'irais plus loint que black Myst, en disant que tu
cherches à attaquer digicode alors qu'il est plus rapide d'utiliser une
clé "sauteuse" pour ouvrir en 20sec la porte, sans effort et sans
possibilité de détection ;-)

Attendons de voir tes résultats ...

A+
TM

<...>

Cherche tu as protèger ton code, ou exploiter la faille dans celui
d'un autre ? ;-)

Les grands manitous de la sécurité prêchent toujours que la sécurité
est l'affaire de tous, et lorsqu'on s'y intéresse, on se fait accuser
d'être un pirate :p

Apporte la preuve (maquette complète) que ce que tu avances existe bien
dans la pratique sur la plateforme Java et qu'il a une probabilité

Je ne comprends pas qu'on me demande d'apporter la preuve pratique
d'existence d'un problème alors que c'est justement la question que je
pose: citation de mon post initial "Je souhaiterai seulement savoir s'il
s'agit d'un problème théorique ou d'un problème que l'on peut vraiment
rencontrer" (ndlr: j'ai corrigé l'erreur sur "rencontrer").

Je pense que je répondrais beaucoup plus aux questions des posteurs de
ce forum s'il fallait qu'en prérequis ils/elles viennent avec les
réponses à leur propres questions ;)

"importante" (tout est relatif, hein!), et on rediscutera tous ensemble
sur le sujet avec plaisir...

heu? Que restera-t-il à discuter alors? ;)

[...]
Attendons de voir tes résultats ...

Je me lancerai éventuellement dans une quête aux résultats lorsque je
serais moi-même convaincu de l'existence d'un problème (qui est bien
l'objet de mon post initial).
Maintenant si on se pose la question de pourquoi je pense qu'un tel
problème peut éventuellement exister, c'était également dit dans le post
initial: je l'ai entendu évoqué à quelques reprises. La plupart du
temps, c'était lors de conversation oral, mais sinon, Joshua Bloch
l'évoque lui aussi rapidement p. 123 de son livre "effective java" (Item
24: Make defensive copies when needed).
Mei

Je me lancerai éventuellement dans une quête aux résultats lorsque je
serais moi-même convaincu de l'existence d'un problème (qui est bien
l'objet de mon post initial).
Maintenant si on se pose la question de pourquoi je pense qu'un tel
problème peut éventuellement exister, c'était également dit dans le post
initial: je l'ai entendu évoqué à quelques reprises. La plupart du
temps, c'était lors de conversation oral, mais sinon, Joshua Bloch
l'évoque lui aussi rapidement p. 123 de son livre "effective java" (Item
24: Make defensive copies when needed).
Mei

J'ai l'impression qu'on est mal partie pour ce comprendre ;-)

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.
- 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.
- 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.


Ensuite, quand je te demande si tu cherche à exploiter une faille ou à
t'en protéger, c'est une vrai question.

La meilleur façon de protéger son code, c'est d'avoir les compétences
pour attaquer afin de comprends quels sont les armes qui peuvent être
utilisé. De plus, essayer de casser la protection n'est pas forcément
illégal, du moment que la personne que tu attaque est d'accords, il
arrive même que les gens te demande d'attaquer leur code (le plus
souvent en espérant que tu échouera) et parfois ils vont jusqu'à te
payer si tu réussie.


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. 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.

Black Myst

<...>

Cherche tu as protèger ton code, ou exploiter la faille dans celui
d'un autre ? ;-)

Les grands manitous de la sécurité prêchent toujours que la sécurité
est l'affaire de tous, et lorsqu'on s'y intéresse, on se fait accuser
d'être un pirate :p

Apporte la preuve (maquette complète) que ce que tu avances existe
bien dans la pratique sur la plateforme Java et qu'il a une probabilité

Je ne comprends pas qu'on me demande d'apporter la preuve pratique
d'existence d'un problème alors que c'est justement la question que je
pose: citation de mon post initial "Je souhaiterai seulement savoir s'il
s'agit d'un problème théorique ou d'un problème que l'on peut vraiment
rencontrer" (ndlr: j'ai corrigé l'erreur sur "rencontrer").
<...>

Je pense que je répondrais beaucoup plus aux questions des posteurs de
ce forum s'il fallait qu'en prérequis ils/elles viennent avec les
réponses à leur propres questions ;)

Je vais donc paraphraser ma toute prémière réponse :
« A ma connaissance, Java n'est pas sensible à ce genre de chose pour
une simple question de prédictabilité. »

En complément, lire les réponses conjointe qui sont faites me semble le
seul prérequis pour une bonne compréhension :o)

A vous de voir (ou lire c'est selon) ;-)

A+
TM