Quant à l'"accès à la mémoire", oublie pas qu'on est dans une VM, même le code "trusted" n'a pas accès à la mémoire autrement que par les objets dont il possède des références. Un scan de la mémoire pour aller y chercher des infos sensibles est exclu dans tous les cas.
Je suis pas du tout un expert en attaque, mais j'ai vu des vecteurs d'attaques vraiment intelligent en manipulant des tas de données de façon experte.
Par exemple, serait il possible de créer une classe de façon dynamique (donc dans aucun ".jar" ou autre), héritant d'une classe privilégié ?
Si oui, comment se comporte le l'utilisation des super classes ? toujours priviligiée normalement (elles appartiennent au .jar autorisé) ? Il serait peut etre possible, non pas de réimplémenter la méthode que l'on veut "attaquer", mais une méthode qu'utilise la méthode que l'on souhaite attaquer. ainsi, en appelant la super classe, il va utiliser notre méthode (je sais plus quel type d'héritage il faut pour que ça marche), qui provoquera soit ce que l'on veut, soit une exception en esperant que lors d'une exception il conserve les droits (enfin voir comment marche la sécurité sur la vm, etc...)
Bref, ne pas forcément dépendre d'une faille (bien qu'une faille dans une lib soit forcément plus probable qu'une faille dans une vm, vu que la taille de code est plus importante), mais des comportement fortement tarabsicoté qui outrepasse les procédures de sécuritées etc...
mais la VM est toujours capable de fournir la pile d'appel, même dans du code qui a été compilé, optimisé, voire inliné. Donc ça ne doit pas poser de problème.
et peut on avoir des classes qui font un "trampoline" dans les lgg utilisant une vm ? (grosso modo implémenter une autre vm dans la vm. En essayant peut etre de faire comme la faille du double chroot).
Avec l'implémentation standard, je suis pas sûr, mais le SecurityManager est un objet parfaitement normal, on peut sans problème en créer une sous-classe capable de changer les permissions à chaud si besoin.
Gérer les permissions a chaud demande a ce que CHAQUE accés soit vérifié. il n'est donc pas aisé de le rajouter après coup si il n'y a pas déjà les hooks associées.
mais ça sera forcément beaucoup plus lourd, et risque de nécessiter pas mal de boulot de config au niveau de l'OS
Ca je suis tout a fait d'accord ;)
[^] # Re: Pourquoi Mono ?
Posté par briaeros007 . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Je suis pas du tout un expert en attaque, mais j'ai vu des vecteurs d'attaques vraiment intelligent en manipulant des tas de données de façon experte.
Par exemple, serait il possible de créer une classe de façon dynamique (donc dans aucun ".jar" ou autre), héritant d'une classe privilégié ?
Si oui, comment se comporte le l'utilisation des super classes ? toujours priviligiée normalement (elles appartiennent au .jar autorisé) ? Il serait peut etre possible, non pas de réimplémenter la méthode que l'on veut "attaquer", mais une méthode qu'utilise la méthode que l'on souhaite attaquer. ainsi, en appelant la super classe, il va utiliser notre méthode (je sais plus quel type d'héritage il faut pour que ça marche), qui provoquera soit ce que l'on veut, soit une exception en esperant que lors d'une exception il conserve les droits (enfin voir comment marche la sécurité sur la vm, etc...)
Bref, ne pas forcément dépendre d'une faille (bien qu'une faille dans une lib soit forcément plus probable qu'une faille dans une vm, vu que la taille de code est plus importante), mais des comportement fortement tarabsicoté qui outrepasse les procédures de sécuritées etc...
mais la VM est toujours capable de fournir la pile d'appel, même dans du code qui a été compilé, optimisé, voire inliné. Donc ça ne doit pas poser de problème.
et peut on avoir des classes qui font un "trampoline" dans les lgg utilisant une vm ? (grosso modo implémenter une autre vm dans la vm. En essayant peut etre de faire comme la faille du double chroot).
Avec l'implémentation standard, je suis pas sûr, mais le SecurityManager est un objet parfaitement normal, on peut sans problème en créer une sous-classe capable de changer les permissions à chaud si besoin.
Gérer les permissions a chaud demande a ce que CHAQUE accés soit vérifié. il n'est donc pas aisé de le rajouter après coup si il n'y a pas déjà les hooks associées.
mais ça sera forcément beaucoup plus lourd, et risque de nécessiter pas mal de boulot de config au niveau de l'OS
Ca je suis tout a fait d'accord ;)