MISC 45

Depuis l'origine, Java utilise différentes technologies pour protéger les postes utilisateurs contre du code malveillant. Combinées, elles permettent une réelle sécurité, rarement mise en défaut. Regardons les différentes barrières mises en place dans une JVM pour interdire l'utilisation de code malveillant.

Combien de temps pourrait résister votre machine face à un attaquant qui a un accès physique à celle-ci ? Le problème est d'autant plus d'actualité que les ordinateurs deviennent de plus en plus mobiles et nous suivent quasiment dans tous nos déplacements. La possibilité d'un vol ou même simplement d'un accès ponctuel est grande. Quant aux informations qu'ils contiennent, surtout lorsqu'il s'agit de nos ordinateurs de travail, leur criticité n'est plus à démontrer.Sur la plupart des machines, démarrer via un token USB, puis monter les disques chiffrés offre une sécurité relativement raisonnable. Encore faut-il avoir suffisamment confiance en l'utilisateur pour qu'il n'installe pas (même par inadvertance) de malwares (et particulièrement des bootkits1), faisant ainsi entrer le loup dans la bergerie.Les normes du « Trusted Computing Group » (TCG) introduisent la notion d'ordinateur de confiance, jetant les bases d'un ensemble de mesures matérielles et logicielles visant à protéger les données de votre machine contre des attaques non seulement logiques mais aussi physiques, allant même jusqu'à se défendre contre l'utilisateur lui-même lorsque celui-ci risque d'en compromettre la sécurité.Tout repose sur des puces spécifiques appelées « Trusted Platform Modules » (TPM) directement installées sur la carte-mère de l'ordinateur. Elles ont été normalisées par le TCG, puis mises en production par un certain nombre de fondeurs (ATMEL, Broadcom, Infineon, Intel, NSC...) et proposent un ensemble de services sur lequel on peut espérer construire une sécurité robuste.Cet article traite des puces TPM [3,8], de leurs capacités et de quelques logiciels de base qui permettent d'en tester le fonctionnement.

Le 3 décembre 2008, Sun a corrigé une faille, découverte et rapportée par Sami Koivu le 1er août 2008. Le rapport de Sun était laconique : « A Security Vulnerability in the Java Runtime Environment (JRE) Related to Deserializing Calendar Objects May Allow Privileges to be Escalated ». Il n'y a là pas grand-chose pour attirer l’œil, si ce n'est l'absence de référence à toute bibliothèque native et à toute corruption mémoire (telle que le classique « buffer overflow ») comme c'est le cas pour la plupart des vulnérabilités Java.